让我们说我有一个场景，我想要显示一个由许多其他业务对象构建的业务对象，即它是深层次的。
要显示数据，我想使用masterDetail类型的视图，但有许多级别，让我可以深入挖掘数据。
所以我想要从对象根目录中的某个列表中选择一个项目，并显示其属性的详细视图，然后从该详细视图中选择一个项目并显示其详细视图等等。
如果我没有与数据交互，那么我就不需要为深层次结构中的每个Model创建viewModel，因为我可以直接绑定到Model。
如果我正在与数据交互，那么我可能希望用视图模型包装整个业务对象及其后代，并绑定到它，允许我添加命令来执行某些逻辑。
但是如果我只想在某些级别与数据进行交互呢？尝试直接从XAML或codeBehind与模型交互将是混乱的。然而，使用ViewModels包装整个内容需要做很多工作。
我想我只会使用转换器在特定点创建viewModels
<DisplayControl DataContext="{Binding A}">
<DisplayControl DataContext="{Binding B}">
<InteractionControl DataContext="{Binding C, Converter{ConvertModelToViewModel}}">
</InteractionControl >
</DisplayControl >
</DisplayControl >
但是如果我需要在那些Viewmodels上执行清理呢？例如取消注册事件。每次我来回查看同一个项目时，它都会为同一个模型创建新的视图模型。我不想依赖垃圾收集，因为保持视图模型可能很昂贵，这取决于他们正在做什么，并且GC可能甚至不会发生（例如，如果我注册到静态类的事件）。使用弱事件对GC有帮助，但在保持昂贵的viewModel比他们需要的时间更长的情况下仍然没有用。
答案 0 :(得分：1)
要对这个问题给出一般性答案并不容易，因为它涉及MVVM应用程序的体系结构，需要考虑很多方面。它可能有助于对决策进行排序并提供一些最佳实践。对此的回答将永远是固执己见的，因为它涉及风格和品味......
现实生活中，复杂的MVVM应用程序无法在没有相当多的基础结构的情况下构建，而这些基础结构通常会被教程忽略。特别是对于构建视图，ViewModel和模型以及将所有内容粘合在一起，有许多可用的概念。
我只想告诉你我如何处理你提到的问题：
我从不直接绑定到模型。随着应用程序的增长，ViewModels往往变得更加复杂，而且不包含任何其他逻辑方面（与模型相比）的ViewModel实际上非常少。更改通知（INotifyPropertyChanged）是另一个方面：将此方面与ViewModel隔离是有意义的，只要更改通知仅用于UI目的。为了可维护性和可扩展性，我建议花费额外的精力。你不想因为你在开始时忘了一些东西而被迫进入一个主要的redsign。
实现基础架构以处理常见的MVVM任务，例如将ViewModel上的集合与视图上的集合同步。 See the answer here for details。我最终构建了一个ViewModelFactory，它处理ViewModels的构造和缓存。这甚至允许回收ViewModel（采用不再需要的ViewModel实例，只需切换模型，类似于回收模式下的UI虚拟化概念）。
当然，这不是你问题的完整答案，但我希望它能帮助你走得更远。如果您有更具体的问题，请随时回复我。