【发布时间】：2011-11-04 00:01:38
【问题描述】：
它在这里总结了我的问题： Double check - does it ever make sense to have internal viewmodel class?
我有controls.DLL，我想保留这个自定义控件绑定和视图模型的内部。但是，这似乎是不可能的。
你如何解决这个问题？我看到它的唯一方式 - 不要使用绑定..
【问题讨论】：
标签： silverlight xaml
【发布时间】：2011-11-04 00:01:38
【问题描述】：
为什么你有一个自定义控件的视图模型？我假设您将视图模型对象分配给 DataContext 属性，但这几乎总是一个错误：DataContext 应该可供消费者随意使用和滥用。换句话说，如果自定义控件的使用者显式设置 DataContext 会发生什么？听起来您的控件将停止工作并引发一堆 xaml 绑定错误。
自定义控件本质上是无形的。没有模型或视图模型，只有一个视图。该视图是 .cs 文件。您通过主题/generic.xaml 文件提供默认外观，但消费者应该能够提供他们自己的模板。如果您将它们绑定到视图模型，它们还需要知道如何创建视图模型实例及其所有依赖项。您刚刚创建了高度耦合的代码。 DI 容器可以放松耦合，但这只是将类之间的关系从“耦合”降级为“相关”。我说，为什么消费者甚至需要知道这些信息？
更好的方法是为您的控件提供所有属性作为依赖属性。然后您的 generic.xaml 可以提供一个控件模板，该模板使用更有效的 TemplateBinding 将属性/对象绑定到您的控件。如果您需要从业务对象填充这些依赖项属性，请公开 IBusinessObject 类型的另一个依赖项属性并在该对象的 PropertyMetaData 更改处理程序中设置派生值。如果您的 IBusinessObject 类型包含另一个实现 INotifyPropertyChanged 的类的属性，您可能应该 (1) 重新考虑您的对象图或 (2) 使用子类在代码中创建 Bnding 对象。
我认为遵循上述所有建议将消除您担心的问题以及其他问题。将视图模型留给 UserControls。是的，这就是为什么自定义控件令人头疼的原因。把它们做好是相当重要的。
【讨论】：
-
生活和学习。我只是从控件开始。我转向 VM，因为我需要绑定，因此我必须设置 DataContext。现在是啊哈！当我意识到 TemplateBinding 的 Dependency 属性就像通过 DataContext 绑定的常规属性一样。我对吗？我有相当复杂的控制，我的也可以是 UserControl。但我认为控制应该更有效？控件的用户是我们，所以我在这里并不真正关心。但同时我想把它做好。现在我明白了。我确定我会发布更多问题:)
-
如果您想允许或提供完全不同的控件外观，您将使用控件。例如，一个时钟控件可以提供一个基本的数字接口，但该控件的用户可以将其重新定义为具有一个模拟接口（甚至是一个二进制接口）。如果您没有这种需求或愿望，请不要使用自定义控件。
-
关于 TemplateBinding，您走在正确的轨道上。它等效于将 Source 设置为“RelativeSource TemplatedParent”的 Binding。由于这个假设，TemplateBinding 提供的功能比 Binding 少，但效率更高。
-
自定义控件不会比 UserControl 性能更好吗？
-
你知道，我只是找不到任何性能信息。我的猜测是 UserControl 实际上性能更高，因为它不必处理模板。来自 UserControl 的文档：“创建从 UserControl 继承的控件的另外两个主要原因是 1) 将功能分成更小的、可管理的逻辑块，这些逻辑块可以独立于应用程序和其他控件创建；2) 对相关控件进行分组可以在应用程序中多次使用。”它只是没有说明性能。
尝试受保护的内部。我想这应该可行。虽然我认为完全不公开 ViewModel 并不是一个好主意，因为它的目的之一是能够针对同一个 ViewModel 定义多个 View，这些 ViewModel 可能来自不同的程序集。
【讨论】：
-
在这种情况下，MVVM 只是更容易编程，内部不起作用。属性和类都必须是公开的