这篇文章旨在列出关于MVVM方法的建议。。。你使用什么工具，你做什么来加快开发，你如何维护你的应用程序，在这个设计模式中寻找缺陷的任何特殊方法。。。。。。
我是这样做的：
因此，首先我用EF创建了我的模型/db。
然后，我创建具有各自视图模型的视图（用户控件或窗口）。我通常将视图模型放置在与视图相同的位置。但是，当我的视图名称以"UC名称"开头时，我将我的视图模型称为"名称模型"。
在我的视图模型中，我实现了InotifyProperty Changed
在我的xaml视图中，我有一个视图模型的资源，并通过itemsource将我的网格/控件绑定到staticsource。
我尝试用触发器和样式做很多前端逻辑，如果xaml.cs文件考虑到控件行为的逻辑，我还会在其中放置一些代码。
我可以从我的视图（xaml+xaml.cs）访问我的视图模型。
为了在视图模型之间进行通信，我使用MVVM灯。
差不多了。
我在想
-
我正在考虑使用T4模板来生成视图模型/视图。你们怎么看。这值吗？
-
当使用MVVM light Messenger时，我们会获得基于订阅的通信，有时我发现很难跟踪我的DataContext中发生了什么变化。对此有什么建议吗？
-
欢迎任何其他改进或建议！
在回答关于View/ViewModel生成的第一个问题时，我认为对于CRUD案例，使用一些工具是有意义的，否则就没有那么大好处。
您可以在这里找到非常好的基本脚手架实现示例：WPFCUDGenerator。此外，DevExpress的WPF解决方案看起来非常有前景。
至少有两个Codeplex项目解决View/ViewModel代：
- WPF脚手架工
- Clarius的ViewModel工具
但对于这种情况，我对T4相当悲观。我认为编写和完善自己的T4将比采用现有工具花费更多的时间。
关于MVVMLight信使，我可以说你需要一些时间来适应它。一旦你了解了"常规"和消息驱动的MVPM之间的区别，你就能够以最有效的方式使用它。关于信使的非常好的文章是信使和MVVM中的查看服务
我想添加一个非常重要的报价：
关于信使的警告
Messenger是一个功能强大的组件，可以极大地简化任务通信，但这也使代码更难调试因为第一眼并不总是清楚哪些物体接收消息。小心使用！
我非常支持领域驱动开发（DDD）。首先，我让设计师编写规范，大致遵循行为驱动开发（BDD）中的方法。这就形成了测试驱动开发（TDD）单元测试的基础，我使用NUnit进行测试。对于域层本身，我从贫血域模型开始，即实体类主要包含属性，实际上没有方法；有很多支持和反对的论点，但我个人认为它很有效。与此相结合的是业务逻辑层（BLL），它只知道域实体。
对于数据访问层（DAL），我更喜欢NHibernate，它支持所有常见的功能，如延迟加载和存储库管理等，但特别重要的是对象关系映射（ORM），即在域实体和底层数据库表示之间转换的位。
在我看来，NHibernate的一个问题是，它使用XML文件为ORM进行映射。这意味着两件事：第一，您引入的任何错误在运行时之前都不会被发现。其次，它根本不是ORM的一个合适的"解决方案"，而不是编写映射类，最终只会编写XML文件。这两个问题都可以通过使用Fluent来解决。Fluent通过用C#文件替换XML文件来解决第一个问题，因此您的映射声明现在是在代码中完成的，这些代码通常会在编译时发现错误。它通过提供一个自动映射器来解决第二个问题，该映射器可以查看实体并自动生成必要的映射文件。如果需要的话，这可以手动覆盖，尽管在实践中我发现我很少需要这样做。由于自动映射器使用反射确实有点慢，但它可以在离线实用程序中运行，然后保存到运行时加载的配置文件中，以便近乎即时启动；同样的实用程序也可以用于自动创建数据库。我在MySql、MS Server和MS Server CE中使用过这项技术。。。他们都做得很好。
在层的另一侧是您的视图模型。我见过很多项目创建了一个几乎1:1的域实体映射来查看模型类，我这样说可能会激怒MVVM纯粹主义者，但我真的不认为为一些不真正需要的东西做所有额外的工作有什么意义。NHibernate允许您为它创建的类提供代理，使用Castle动态代理，您可以为NHibernaate会话工厂设置一个拦截器，该拦截器会自动向所有实体属性注入INotifyPropertyChanged通知，以便它们与WPF绑定机制一起工作。另一个产品uNhAddIns允许您用ObservableCollection替换任何列表，以获得INotifyCollectionChanged支持（由于我不想深入讨论的原因，您不能在不严重影响性能的情况下将ObservableCollections放入实体中）。
如果您在设计和构建应用程序时正确地使用了这些技术，并在此过程中进行了完整的单元测试，那么您将需要某种方式来处理控制反转（IoC），这样您就不会到处传递对象引用，为此，您将需要一个依赖注入框架。我个人更喜欢Ninject，但Unity也很不错。依赖注入对于良好的数据库会话管理（以便所有相关对象引用同一会话）特别重要，一个好的规则是每个WPF表单一个会话或每个web请求一个会话。
我还有很多其他的小东西可以让生活变得更轻松（MVVM Lite、log4net、Moq用于模拟单元测试的对象等），但这是我的核心架构。设置需要一段时间，但一旦一切就绪，您就可以在几分钟内构建功能齐全的数据库应用程序，而不会出现传统上与分层企业应用程序中的层管理相关的任何麻烦。。。你只需要创建你的域实体，然后开始为它们编码。您的架构是自动创建的，数据库是自动创建，您可以使用实体类来填充数据库以进行即时压力测试，并且您拥有完全的WPF支持，而不必用与域无关的代码或属性污染实体类。由于所有的开发都是由贫血的域实体驱动的，当你想为你的应用程序提供web功能时，你的数据已经是可以序列化为html/ajax/soap等的完美格式了。
您会注意到，我还没有讨论演示文稿/XAML层，主要是因为该部分现在很简单。使用一个像样的体系结构，您实际上可以创建一个完全可工作和测试的应用程序，然后只需要添加纯XAML即可将其变成可发布的产品。