在 WPF 中编写太多自定义控件的问题答案

【问题标题】：Problems writing too much custom controls in WPF在 WPF 中编写太多自定义控件的问题
【发布时间】：2014-07-23 13:22:27
【问题描述】：

我正在开发新的 WPF/MVVM 项目，我看到几乎所有控件都是针对不同需求编写的，从文本框到树视图。所有都为了简单的需要而重写，例如，网格，堆栈面板控件被重写以在每个项目之间添加空间，并且文本框被重写以包含它的标签，以便它本身具有标签和文本输入。

我的问题：由于这种定制，我们会遇到任何严重的问题吗？我已经看到对齐所有控件的问题，因此我会看到更多问题吗？

【问题讨论】：

当你说“重写”时，你的意思是“你有自定义代码来重新实现每个控件”还是“你有每个控件的自定义样式”？还是您只是说项目中有很多自定义控件，而您并没有真正“重写”现有控件？
我的意思是通过添加的属性或功能重新实现每个控件，并且重新设置控件的样式（我的意思是覆盖其控件模板）
开发时必须选择正确的控件。有些控件会考虑它们所在容器的对齐方式，有些则不会。有些有HorizontalContentAlignment，有些只有HorizontalAlignment。如果要添加“XAML 属性”，则只需为该控件实现依赖项属性。 WPF 与 WinForms 完全不同，因此编写自定义控件并不经常发生。
NETscape，我同意你的观点，我也有同样的疑问，因为 WPF 提供了大部分属性。我的架构师给出的原因是，1. 这将有助于正确显示验证错误，2. 我们进行自己的对齐和样式设置。现在，我的问题是，它会对应用程序的整体性能产生什么影响。
@Senthilkumar：告诉你的架构师阅读更多关于样式和主题的信息。它提供了他正在寻找的东西。

【解决方案1】：

您不应该创建自定义控件或用户控件来添加边距、向文本框添加标签或向ListBox 添加新的ItemTemplate。

UserControls 用于将常用的控件组合分组到一个可重复使用的控件中。一个示例可能是打开对话框的自定义 List-of-Values 控件。这可以作为UserControl 实现。

当本机控件不适合您的需要时，自定义控件是很好的选择。假设您想从头开始重新实现 DateTimePicker，因为本机不包括毫秒。

没有这样的严重问题，但您可能会发现自己在接下来的很多年里都在维护所有这些控制，而没有必要这样做。

设置边距应在您使用它的View 中完成，或者在ResourceDictionary 中的Style 中完成。

这当然只是我的观点（以及许多其他人的观点，我除外），但如果您发现您的大多数控件都是以这种方式“自定义”的，那么您就错了。

Style 和 Templates 而不是 UserControls 和自定义控件。

主要问题是您无法仅在单个视图中更改边距。如果您更改自定义控件的内部填充和边距，您将更改解决方案中的所有视图。如果您使用样式，则始终可以通过在视图中定义新样式或直接设置属性来覆盖它。

【讨论】：

您是否发现任何性能瓶颈？或者它可能导致的任何类型的内存泄漏？我在 vs2013 中看到了很多好的功能，如果我使用自定义控件，我是否能够使用这些功能（例如 xaml 绑定和资源映射中的智能感知、内存管理技术）。
@Senthilkumar：您通过添加更多控件使可视化树变得更大。这会稍微降低性能。 Intellisense 和绑定将正常工作。您将只是编写许多无用的额外代码。 WPF 中的内存泄漏主要发生在（根据我的经验）未正确取消订阅的事件订阅中。我对这种方法的主要问题不是性能，而是事后必须维护它。您创建控件的唯一目的是声明样式。这就是样式的用途。
@Troles，感谢您的回答和时间。除了习惯这种方法我别无选择，我只想检查它是否是好的方法。
@csensoft：嗯，我为你感到难过 :) 在过去的 7 年里我一直在使用 WPF，但我从未听说过有人采用这种方法。我也找不到这样做的理由。
@Troles，是的，我也有 5 年的经验，我从未创建过几个自定义控件（仅用于特定需要，它不是 WPF 库的一部分）..