我一直在阅读 Steven Sanderson 的 Pro ASP.NET MVC Framework，其中第 11 章讨论了数据验证。
在第 390 页，我们看到将验证逻辑移动到模型层部分。在本节中，我们在第 392 页看到一些显示如何实现验证的代码。
该代码实现了 GetRuleViolations() 方法，并且 Save() 方法使用该方法在出现问题时抛出 RuleException。
然而，在我看来，域层和数据访问层之间没有区别，代码如下：
public void Save() {
var errors = GetRuleViolations();
if (errors.Count > 0)
throw new RuleException(errors);
// Todo: Now actually save to the database or whatever
}
private NameValueCollection GetRuleViolations() {
// validations...
}
在我正在工作的项目中，我有一个域层尽可能不了解持久性，以及数据访问层，通过NHibernate实现数据访问，并实现在域层中定义接口的存储库。
如果我按照作者在这里建议的那样实现验证规则，则在“Save()”方法上，它们将位于我的数据访问层上，尽管至少我认为它们应该驻留在域上模型！
所以，我的问题是：在创建分层应用程序时，使用域层实现域实体并向存储库公开接口（持久性无知） ，数据访问层实现域层的存储库并实现所有数据访问代码，验证规则应该驻留在哪里？
我的主要（或至少第一个）界面将是 ASP.NET MVC 应用程序（如果这可能会改变什么）。
谢谢。
I've been reading Pro ASP.NET MVC Framework, Steven Sanderson, and in chapter 11 it discusses data validation.
On page 390 we see the section Moving Validation Logic into Your Model Layer. In this section we see, in page 392, some code showing how to implement validation.
The code implements a GetRuleViolations() method and the Save() method uses it to throw a RuleException if something was not alright.
It looks to me, however, that there's no distinction between the Domain Layer and a Data Access Layer, here's the code:
public void Save() {
var errors = GetRuleViolations();
if (errors.Count > 0)
throw new RuleException(errors);
// Todo: Now actually save to the database or whatever
}
private NameValueCollection GetRuleViolations() {
// validations...
}
In a project I'm working, I have a Domain layer, as persistence-ignorant as possible, and a Data Access layer, implementing data access through NHibernate, and implementing the repositories which interfaces were defined in the Domain layer.
If I implement the validation rules as the author proposes here, on the "Save()" method, they would go on my Data Access layer, although, at least I think, they should reside on the domain model!
So, my question is: when creating a layered application, with a Domain layer implementing the domain entities and exposing interfaces to repositories (persistence ignorant), a Data Access layer implementing the repositories from the domain layer and implementing all the data access code, where should the validation rules reside?
My primary (or at least first) interface will be an ASP.NET MVC application, if that might change anything.
Thanks.
发布评论
评论（3）
在 MVC 架构中，M（模型）包括域层和数据访问层。所以桑德森的例子并没有什么问题。
也就是说，当您使用这两个层（而不是只有一个层）实现域模型时，验证逻辑应该转到域层以增加域对象的内聚性，并避免验证逻辑在许多地方重复（例如在每个具体的地方）。存储库）。
In an MVC architecture, the M (model) includes both the domain layer and data access layer. So there's nothing wrong with Sanderson's example.
That said, when you implement your domain model using both these layers (instead of having only one), validation logic should go to the domain layer to increase the cohesion of domain objects and avoid validation logic to duplicated in many places (e.g. in each concrete repository).
它们绝对属于您的域层（您可以在其中实现
IDataErrorInfo，但我认为这只对 Windows 窗体或 WPF 应用程序有用）。看起来这种验证理念与 Paul Stovell 所揭示的理念非常相似（查看 他的这篇文章）。它非常强大，我经常使用它。基本上 ：
因此，尽管您的域层对持久性问题一无所知，但我相信您的实体至少应该知道它们何时被持久化。 Save 方法是一种让它们对自己的持久性负责的方法（它们随后可以委托给数据访问层）。我看不出这有什么问题。
They definitely belong to your Domain Layer (where you could implement
IDataErrorInfo, but that would only be useful for Windows Forms or WPF applications I think).It looks like this validation philosophy is very similar to the one exposed by Paul Stovell (check out this article of his). It is very powerful and I use it a lot. Basically :
So, as ignorant as your Domain Layer is of persistence matters, I believe your entities should be at least aware of when they are being persisted. The
Savemethod is a way to make them responsible of their own persistence (that they can subsequently delegate to a Data Access Layer). I can't see anything wrong with this.我通常更喜欢始终有效的域对象。
域对象只能通过防止对象变得无效的方法来更改。
另一方面，表示对象可能包含临时无效值或无法正确解析的值。但只有当数据有效时，表示层才会向域对象发出方法调用。
领域对象强制执行不变量，表示对象向用户指示应如何修改其输入以遵守约束。
I usually prefere always valid domain objects.
Domain objects can only be changed by methods that prevent the object to become invalid.
On the other side, the presentation objects can contain temporary invalid values, or values that cannot be parsed correctly. But methods calls will only be issued to domain objects by the presentation layer when the data is valid.
Domain objects enforce invariants, presentation objects indicates to user how it should modify its input to respect constraints.