WPF最佳实践：自定义控件是否适用于MVVM设计？

我正在寻找创建一个我可以在我的页面上重用的通用控件：一个AddressControl，它有Address1，Address2，City，State，Zip等…

最初我刚刚创建了一个包含所有这些项的类（ AddressEntity ）并实现了INotifyPropertyChanged 。 我在AddressControl的Code-Behind中将该类作为DependencyProperty包含在内，并将其用作DataContext以绑定其属性。

然后，有人说我的代码很难看，我应该看看MVVM。 看着它，我认为：

• AddressEntity.cs只是数据的容器（即Address1，Address2等）和成员（即Clone，ToString等）
• 我需要一些AddressViewModel来包装我的AddressEntity并提供PropertyNotification更改，validation等。
• 我需要以某种方式为此提供“视图”。

问题是我见过的每个例子都有一个UserControl作为View而不是CustomControl。 在我深入研究之前……

• 是否可以在此示例中使用MVVM +自定义控件？
• 除了UserControl与CustomControl的主要区别之外，它与View几乎完全相同（UserControl vs CustomControl）吗？ 基本上，我的CustomControl真的只是一个视图吗？

参考： WPF的Model-View-ViewModel（MVVM）设计模式

Answer 1

CustomControls永远不会用mvvm完成。

您想要的是数据的可重用视图（用户控件），而不是控件（自定义控件）。

UserControls和CustomControls是两个完全不同的野兽。

编辑：

尽管UserControls最初是为什么开发的，但在MVVM中，当您需要特定于模型/视图模型的可重用视图时，通常会使用UserControl。 它只是XAMl没有任何代码（除了自动生成的InitializeComponent东西）。 通常，您将UserControl保存在您使用它的同一个项目中。

当您需要一个通用的function需要视图并且甚至可能超出当前应用程序范围时，您可以使用CustomControl。 这里控件实际上是在代码文件中定义的，外观（可以覆盖）来自资源字典中的XAML。 通常，您将CustomControl保存在一个单独的ControlLibrary项目中，并引用您希望在其中使用的项目中的库。

在充分尊重WallStreetProgrammer的情况下，仅根据您是否需要无外观控制来在用户控件和自定义控件之间进行选择有点天真。

Answer 2

使用MVVM时，Model和ViewModel不应该依赖于View，也就是说它们不应该关心使用它们的视图类型。

自定义控件和WPF中的用户控件之间的区别在于自定义控件是无外观的，可以通过其ControlTemplate进行自定义。 如果您正在编写通用控件库（如Microsoft），那么您应该编写这些内容。 但是，如果你有一个特定的外观让你控制，只需使用一个用户控件，它会快得多，但只有一个外观，你为它定义的那个。

在MVVM项目中使用自定义控件和用户控件的混合是很常见的。 例如，您可能会使用Microsoft的一堆自定义控件（如文本框和文本块）并将它们组合到用户控件中。

请参阅控制创作概述