Question

我正在编写一个使用NHibernate作为我的ORM的ASP.NET MVC应用程序。我虽然在设计上有点挣扎，但想要一些输入。

所以，我的问题是我在哪里放置我的业务/验证逻辑（例如，电子邮件地址需要@，密码＆gt; = 8个字符等等）？

所以，这最有意义：

将它放在域对象本身上，可能是在属性设置器中？
在我的域图层上方引入一个服务图层，并为每个域对象设置验证器？
维护两组域对象。一个用于NHibernate的哑设置，另一个用于业务逻辑的智能设置（以及它们之间的某种适应层）。

我想我主要担心将所有验证放在NHibernate使用的域对象上。每次从数据库中提取对象时，进行不必要的验证检查似乎效率低下。要清楚，我认为这是一个真正的问题，因为这个应用程序将非常苛刻（在一些表中想想数百万行）。

更新：我删除了一行有关NHibernate的错误信息。

Answer 1

澄清一些错误观念：

a）NHib 不要求您映射到属性。使用access strategies，您可以轻松地映射到字段。如果您更喜欢使用属性或字段以外的其他内容，也可以定义自己的自定义策略。

b）如果确实映射到属性，getter和setter，不需要公开。他们可以受到保护甚至是私人的。

话虽如此，我完全同意，当您从数据库中检索实体时，域对象验证没有意义。因此，我会使用在用户尝试更新实体时验证数据的服务。

Answer 2

我目前的项目与你的项目完全相同。使用MVC作为前端，使用NHibernate作为持久性。目前，我的验证是在服务层（您的选项2）。但是在我编写代码时，我感觉我的代码并不像我希望的那么干净。例如

public class EntityService
{
    public void SaveEntity(Entity entity)
    {
        if( entity.Propter1 == something )
        {
            throw new InvalidDataException();
        } 
        if( entity.Propter2 == somethingElse )
        {
            throw new InvalidDataException();
        }  
        ...
    }
}

这让我觉得EntityService是一个“神级”。它对Entity类知之甚少，我不喜欢它。对我来说，让实体课程担心自己感觉好多了。但我也理解您对NHibernate性能问题的关注。所以，我的建议是在Setters中实现验证逻辑，并使用NHibernate映射的字段。

NHibernate妥协域对象

2 个答案: