您将验证逻辑放在哪里

在这种场景中，我支持一种非常广泛使用的方法，那就是引入视图模型的概念：一个聚合要在表单中显示的所有数据的类，它指定（通过属性或其他机制）应该对这些数据执行哪种类型的验证。

这种方法有几个好处，包括：

• 将验证逻辑与模型解耦（也许现在有一些验证场景你想强制执行，但不是数据本身固有的）；通过这种方式，您能够为应用程序的不同部分定义不同的验证场景，其中相同的业务对象发挥作用（例如，在业务逻辑的某些部分中，每个人都必须有配偶，但拥有配偶并不是每个人的固有属性）
• 将验证与表示逻辑（视图的代码绑定）解耦；这样，您就不必将表示行为与业务对象验证特别纠缠在一起
• 验证代码是孤立的，其每个部分仅针对特定类型的验证；通过这种方式，验证代码可以在应用程序中重复使用，只要它适用

进行验证的实际代码通常在一个单独的验证类中；您的视图模型只会规定每一条验证应该如何应用于每一条数据。

每个业务对象。我已经经典地让每一个实现了一个IValidator接口，该接口会吐出对象的所有验证错误。

在业务对象中。原因是您希望您的验证规则是可测试的。如果规则很重要，你会想用测试来覆盖它们，如果它们不重要——一开始就不要实施它们。把这一点发挥到极致，可以得到代码库非常薄并且几乎没有任何逻辑的代码。这是一种渴望。

这里有一些好的练习：http://colinjack.blogspot.com/2008/03/domain-model-validation.html

一旦就位，在域模型中，UI应该能够反映模型的验证状态/输出。