我将 MVVM 与 Prism 和 Silverlight 一起使用。我对一个模型有多种不同的看法。当我写更多视图时，他们的 ViewModel 似乎重复了很多与处理这个模型相关的通用代码。与其在所有虚拟机中重复相同的通用代码，我更倾向于将其推回模型中（这可能会过多地混淆关注点）。或者可能是一些常见的 ViewModel 基类？或者我的虚拟机可能需要它们和模型之间的第二级“共享虚拟机”？这个单一的共享实例，二级虚拟机将整合多个常规虚拟机共享的行为和状态。
对这些问题和可能的方法有何评论？
感谢您的评论。我可能应该告诉你更多关于有问题的特定“共享”VM 代码的信息。
我可以看到将一些未来代码放入 VM 基类中，但我正在查看的特定“共享”代码似乎属于模型本身实现的 INotifyPropertyChanged。这部分基于另一个线程。
我不认为这违反了 SoC，因为该模型本质上是动态的。它的某些属性仅在特定时间有效。模型的动态特性不仅对 UI 很重要，适当的单元测试也会关心它。因此这个模型似乎需要一个 INotifyPropertyChanged。
对此有何评论？
如果公共代码可以由所有ViewModel 共享，那么值得将其放入基本 ViewModel 类型中。
如果公共代码仅由与特定模型交互的 ViewModel 共享，那么“共享”的 ViewModel 就是要走的路。
各种 MVVM 框架中的大多数“基本 ViewModel”类都倾向于包含对 INotifyPropertyChanged 的支持，并且通常对调度回 UI 线程提供某种支持。
除此之外，我认为，如果您有许多 ViewModel 共享功能，这些功能应该放在基类中，我使用这种模式的次数越多，我发现自己使用的 ViewModel 层次结构就越浅，这是所有代码通用的基本 ViewModel视图模型，通常是另一个基类，用于 UI 的该区域中的通用功能。通常是常用命令或 UI 共享元素的地方。
ViewModelBase -> ProductsViewModelBase -> NewProductViewModel
在完全是 MVVM 的SoapBox Core中，我定义了一个 IViewModel 接口和一个 AbstractViewModel 基类，正如 Nigel 所说，它只是实现了 INotifyPropertyChanged。（请注意，SoapBox Core 是 WPF，而不是 Silverlight，但在这种情况下，这没什么大不了的。我也做过一些类似的 Silverlight 工作。）
然后我定义了更多从 IViewModel 继承的接口（如 IMenuItem）和更多提供这些接口基本实现的抽象类。
现在，这说明了整个 ViewModel 树，但正如您所说，还有模型树。我现在已经花了将近一年的时间使用 MVVM，这是我最大的顿悟：不要编写模型。如果您从头开始构建应用程序，只需将所有内容都放在 ViewModel 中，否则您最终会复制大量代码。
唯一让我烦恼的情况是，当我使用未实现 INotifyPropertyChanged 的 3rd 方库时，因此不容易绑定。我相信实体框架的自动生成代码也可能在这里，但我注意到一些实体框架现在为您提供了在实体本身中实现 INotifyPropertyChanged 的选项。
说真的，我们应该将它重命名为 ViewModel 模式并完成它。:)
我已经成功地使用了纽约时报 Silverlight 工具包中 ViewModels 的继承来减少重复的代码。以 CommunityRecentComments 及其父类 CommunityBase 为例。