这篇文章旨在提供有关MVVM方法的建议列表...您使用了哪些工具，如何加快开发，如何维护应用程序，以及在此设计中查找缺陷的任何特殊方法图案......
这就是我的所作所为：
首先我用EF创建我的模型/数据库。
然后我使用各自的viewmodel创建视图（用户控件或窗口）。我通常将viewmodel放在与我的视图相同的位置。但是在用“UC-name”开始我的视图名称时，我将我的viewmodel称为“名称模型”。
在我的viewmodel中，我实现了InotifyPropertyChanged
在我的xaml视图中，我有一个viewmodel资源，并通过itemsource将我的网格/控件绑定到staticresource。
我尝试使用触发器和样式执行大量前端逻辑，并在xaml.cs文件中放置一些代码，如果它关注我的控件行为的逻辑。
我可以从我的视图（xaml + xaml.cs）到达我的viewmodel。
用于视图模型之间的通信我使用MVVM灯。
这就是它。
我正在考虑的事情
我正在考虑使用T4模板生成视图模型/视图。你们怎么想这个呢？这值得吗？
使用MVVM light Messenger时，我们会收到基于订阅的通信，有时我发现很难跟踪DataContext中的更改。对此有何建议？
欢迎任何其他改进或建议！
答案 0 :(得分：2)
回答有关View/ViewModel代的第一个问题我认为对于CRUD案例来说，使用某些工具是有意义的，否则就不会那么有用了。
非常好的基本脚手架实现示例，您可以在这里找到：WPF CRUD Generator。 DevExpress WPF solution看起来也很有希望。
至少有几个解决View/ViewModel代的 Codeplex 项目：
但对于这种情况，我对 T4 非常悲观。我认为编写和抛光自己的T4将比采用现有工具花费更多的时间。
<小时/> 关于 MVVMLight 信使我可以说你需要一些时间来适应它。只要您了解“常规”和消息驱动的 MVVM 之间的区别，您就能够以最有效的方式使用它。关于信使的非常好的文章是Messenger and View Services in MVVM。
关于Messenger的谨慎言辞
Messenger是一个功能强大的组件，可以极大地方便任务 通信，但它也使代码更难调试 因为乍一看并不总是清楚哪些物体 收到一条消息。小心使用！
答案 1 :(得分：1)
我非常支持域驱动开发（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 Dynamic Proxy，您可以设置一个intercepter到您的NHibernate会话工厂，该工厂会自动将INotifyPropertyChanged通知注入所有实体属性，以便它们与WPF绑定机制一起使用。另一个产品uNhAddIns允许你用ObservableCollection替换任何列表以获得INotifyCollectionChanged支持（因为我不会进入你的原因不能只将ObservableCollection放入你的实体而不会严重影响性能）。
如果您正在使用这些技术正确地设计和构建应用程序并沿途完全进行单元测试，那么您将需要一些处理控制反转（IoC）的方法，这样您就不会传递对象遍布各处的引用，为此你需要一个依赖注入框架。我个人的偏好是Ninject，但Unity也很不错。依赖注入对于良好的数据库会话管理尤其重要（因此所有相关对象都引用相同的会话），一个好的规则是每个WPF表单一个会话或每个Web请求一个。
我还有很多其他的小东西可以让生活更轻松（MVVM Lite，log4net，Moq用于模拟单元测试对象等），但这是我的核心架构。设置需要一段时间，但是一旦你完成所有工作，你可以在几分钟内构建功能齐全的数据库应用程序，而不会出现传统上与分层企业应用程序中的层管理相关的任何麻烦......你只需创建域实体和然后开始编码。您的模式是自动创建的，您的数据库是自动创建的，您可以使用实体类来填充数据库以进行即时压力测试，并且您可以获得完整的WPF支持，而无需使用与域实际不相关的代码或属性来污染您的实体类。并且由于所有开发都是由贫血域实体驱动的，因此当您想要提供应用程序Web功能时，您的数据已经完美地格式化为html / ajax / soap等序列化。
您会注意到我没有讨论过演示文稿/ XAML层，主要是因为该部分现在很简单。使用一个体面的架构，您实际上可以创建一个完全工作和测试的应用程序，然后只需要添加纯XAML将其转换为可释放的产品。