MVVM：瘦ViewModels和Rich Models
我将继续努力克服MVVM模式，并且在尝试为小型/中型项目创建实用设计时，遇到了许多挑战。 其中一个挑战是弄清楚如何在不创建大量重复，难以维护的代码的情况下获得与此模式解耦的好处。
我目前的策略是创建“丰富”的模型类。 他们充分意识到它们将被MVVM模式消耗并实现INotifyPropertyChanged，允许观察它们的集合并且仍然认识到它们可能总是被观察。 我的ViewModel类往往很薄，只在实际需要转换数据时公开属性，其大部分代码是RelayCommand处理程序。 视图可以直接绑定到ViewModel或Models，具体取决于是否需要进行任何数据转换。 我使用AOP（通过Postsharp）来缓解INotifyPropertyChanged的痛苦，这样就可以很容易地以这种方式使我的所有Model类“丰富”。
使用这种方法有明显的缺点吗？ 我可以假设ViewModel和View是如此紧密耦合，如果我需要View的新数据转换，我可以根据需要将其添加到ViewModel中吗？
我认为你的模型上的INotifyPropertyChanged只有当你期望你的VM和外部“力”同时操作时才有用。
我个人是POCO模型的支持者。 将任何特定于框架的脚手架放入我的模型中会让我担心。 当您将一个事件放入模型类时，您必须仔细考虑模型的生命周期，序列化，存储等可能存在的问题。例如，如果从数据源重新创建对象会发生什么，而旧的INotifyPropertyChanged订阅现在无效？
ObservableCollection类似地更好的位置在VM中，它可以使用IEnumerable数据源，并且仅向视图呈现选定或临时过滤的项目。
我认为这是务实的方法 – 我们过去成功地遵循了这种模式。
基本前提是直接绑定到为大多数只读数据实现INotifyPropertyChanged的模型，然后为viewmodel添加额外的属性以查看需要转换的视图特定内容（如您所建议的）。 对于非只读属性，我们发现创建viewmodel条目（通常是string类型）最简单，因为这样可以在viewmodel中轻松添加客户端validation。
免责声明 – 我不是专家 –
我没有把INotifyChanged放在我的模型上。 我最初做过这个，但是简单地认识到INotifyChanged实际上只是用于通知UI所以我现在只将INotifyChanged放在我的ViewModel上。 这使得更容易控制“RaisePropertyChanged”的数量……我的观点从不直接引用模型。
我正在开发我的第一个MVVM项目，我的第三个主要重构是：P
我同意View和ViewModel之间会有紧密耦合。 但是，通过尽可能使用IValueConverters进行转换，可以在一定程度上缓解这种情况。
我尝试将我的业务逻辑保留在我的ViewModel中。 此外，我使用Viewmodel来更改我的模型的形状以适合View可能期望的形状。