我正在将 MVVM 模式用于带有 WPF GUI 的新 .Net 软件。使用 IDataErrorInfo 的属性验证进展顺利，所有字段都亮起。但是我正在寻找一种实现某种业务逻辑的好方法。
简单的例子；如果您有一个包含列的表，我正在使用 IDataErrorInfo 接口来检查名称是否为空/有效。但我也想确保列名是唯一的。也可能是该列正在其他地方使用，因此无法删除。
关于如何使用 MVVM 实现业务逻辑有什么建议吗？一直在环顾四周，似乎找不到“解决方案”。
【问题讨论】：
标签： .net wpf validation mvvm
在使用 MVVM 模式时，业务逻辑的位置始终是一个难题。问题始终是视图模型还是模型？
我猜这取决于你在哪里检查重复。
如果您试图阻止用户复制视图中显示的数据，那么您将在关联的视图模型中进行检查。
如果您试图阻止用户复制模型中或相关数据层（读取数据库）中存在的数据，则应在模型域中执行。
您需要记住的唯一一件事是，您的代码将有关重复的数据呈现给视图，但由视图决定是否呈现它。
我经常将大量业务逻辑和“帮助”函数放在一个单独的类库项目中，并从感觉最好的地方调用功能。这样可以更轻松地将功能从视图模型切换到模型，反之亦然。
您看过 msdn MVVM 模式页面吗？看看here。
请记住，尽管在所有事情上都需要采取务实的方法。有时可能会将明显的业务逻辑放在 View 代码后面，但应始终保持在最低限度。
【讨论】：
我想推荐这本书（链接到 Amazon.com）： Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern
虽然它的标题中只有 MVVM，但它提供了广泛的主题以及组织和构建应用程序的可能方法。
我在里面发现了很多有用的想法和建议。
我看到的唯一缺点是它不会太深入单个主题。另一方面，您可以快速阅读，无需按顺序阅读每一章，而是专注于您要查找的内容。
本书可帮助您大致了解您想了解的内容，以及一个很好的起点，以便您以后深入了解。
【讨论】：
在我在 WPF 和 Silverlight 中使用 MVVM 时，业务逻辑通常在域层中更深入地实现，各种消费者可通过服务访问。至于以这种更抽象的方式实现领域逻辑，根据应用程序的复杂性和业务规则的动态程度，有无穷无尽的选择。
有些人会说，域对象的验证应该在 IOC 可注入验证服务中进行，而不是嵌入到域对象本身中（除非它是绝对核心的、不变的域逻辑）。
我通常觉得这种方法有点矫枉过正。您可以让您的域对象实现某种验证接口，该接口可能会将验证链接到整个对象图。域对象可以以内置或动态方式加入可共享的业务规则，例如检查域对象及其相关对象的状态并将条目添加到损坏的业务规则集合的规则。
【讨论】：