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