几乎总结了我的问题： Double check - does it ever make sense to have internal viewmodel class?
我有controls.DLL，我想保留这个自定义控件绑定和viewmodel的内部。但是，这似乎不可能。
你如何解决这个问题？我看到它的唯一方法 - 不要使用绑定..
答案 0 :(得分：1)
为什么您有自定义控件的视图模型？我假设您将视图模型对象分配给DataContext属性，但这几乎总是一个错误：消费者可以随意使用和滥用DataContext。换句话说，如果自定义控件的使用者显式设置DataContext会发生什么？听起来你的控件将停止工作并抛出一堆xaml绑定错误。
自定义控件本身就是无法看到的。没有模型或视图模型，只有视图。该视图是.cs文件。您通过themes / generic.xaml文件提供默认外观，但消费者应该能够提供自己的模板。如果您将它们绑定到视图模型，则还需要知道如何创建视图模型实例及其所有依赖项。您刚刚创建了高度耦合的代码。 DI容器可以松开耦合，但这只会降低类之间从“耦合”到“相关”的关系。我说，为什么消费者甚至需要知道这些信息？
更好的方法是将控件的所有属性作为依赖项属性提供。然后，您的generic.xaml可以提供一个控件模板，该模板使用更高效的TemplateBinding将属性/对象绑定到控件。如果需要从业务对象填充这些依赖项属性，请公开IBusinessObject类型的另一个依赖项属性，并在该对象的PropertyMetaData更改处理程序中设置派生值。如果你的IBusinessObject类型包含一个属性，它是另一个实现INotifyPropertyChanged的类，你可能应该（1）重新考虑你的对象图或（2）使用子类在代码中创建一个Bnding对象。
我认为遵循以上所有建议将消除您所关心的问题以及其他问题。将视图模型保留给UserControls。是的，这就是为什么自定义控件是一个非常令人头疼的问题。正确地做到这一点非常复杂。
答案 1 :(得分：0)
尝试受保护的内部。我认为这应该有效。虽然我认为让ViewModel完全不公开是个好主意，但其原因之一是能够针对相同的ViewModel定义多个视图，这些ViewModel可能来自不同的程序集。