我使用的是棱镜和Silverlight MVVM。 我有一个模型的多个不同的看法。 当我写更多的意见他们的ViewModels似乎复制了很多共同的代码有关处理这一个模型。 而不是所有的虚拟机重复相同的通用代码我很想把它推回模型（这可能会混关注太多）。 或者，也许到一些常见的ViewModel基类？ 或许我的虚拟机需要“共享VM”的他们和模型间的第二级？ 这种单一的共享实例，2级-VM将巩固由多个常规VM共享行为和状态。
对这些问题和可能的途径有何评论？
感谢您的意见家伙。 我大概应该有更多的告诉你具体的问题“共享” VM代码。
我可以看到把一些未来的代码在虚拟机中的基类，但具体的 “共享”的代码我看着似乎在通过模型本身实施的INotifyPropertyChanged的归属。 这部分是在此基础上其他线程 。
我不认为这违反了SoC的，因为该模型本质上是动态的。 它的一些属性只在某些时候有效。 该模型的那动态性不只是东西是对UI重要的，适当的单元测试也关心它。 因此，这种模式似乎需要一个INotifyPropertyChanged的。
任何评论了？
如果通用代码可以被所有的ViewModels共享，那么这是值得把它变成一个基础视图模型类型。
如果通用代码只能通过与特定模型进行交互的ViewModels，然后共享一个“共享”视图模型是要走的路。
我用在继承的ViewModels 纽约时报的Silverlight工具包成功地减少重复的代码。 看看CommunityRecentComments和它的父类CommunityBase为例。
在各种MVVM框架的大部分“基地视图模型”类往往含有派遣回UI线程INotifyPropertyChanged的和支持的支持通常是某种。
除此之外，我认为，如果你有很多的ViewModels的共享functionaltiy应该是进入一个基类，我越使用这个模式，我觉得更多的自己使用的ViewModels的比较浅的层次结构，基本视图模型代码共同所有视图模型，并且通常根据该另一个基类为在UI的那个区域共同功能。 一般常用命令或其中UI是共享元素。
ViewModelBase - > ProductsViewModelBase - > NewProductViewModel
在肥皂盒核心 ，这是完全MVVM，我所定义的IViewModel接口，并且其中，因为奈杰尔说，刚实现INotifyPropertyChanged一个AbstractViewModel基类。 （请注意，肥皂盒核心是WPF，Silverlight的不是，但在这种情况下，它不是一个大问题。我已经做了一些类似的Silverlight工作为好。）
然后，定义了多个接口（如IMenuItem）从IViewModel和更抽象类，它们提供这些接口的基本实现继承。
现在，占全视图模型树，但正如你所说，这里还有模型树。 我花了将近一年，现在用MVVM工作，这里是我的大顿悟：不要写一个模型。 如果您正在构建从地上爬起来的应用程序，只是把一切都在视图模型，否则你最终会复制一吨的代码。
在那里我打扰有模型中唯一的情况下，当我使用未执行INotifyPropertyChanged，因此不容易绑定到一个第三方库了。 我认为，实体框架自动生成的代码可能落在这里为好，但我注意到，一些实体框架，现在给你在实体本身执行INotifyPropertyChanged的的选项。
严重的是，我们应该将其重命名视图模型模式，并用它做。 :)
