域逻辑与数据验证

Question

我正忙着阅读并享受Mark Seemann在.Net中的依赖注入.

我很难解释确切的背景,所以如果你熟悉这本书,请不要理会这个问题.

我的问题与第2章第49页中的两个产品类有关.域层中有一个,数据访问层中有一个.解释了数据访问层中的Product类是由Linq to Entity向导创建的.

我正在使用Linq to SQL,我可以使用Ling to SQL属性来装饰我的模型类,这样我就不必拥有第二个类.例如

[Table(Name="Customers")]
public class Customer
{
  [Column(IsPrimaryKey=true)]
  public string CustomerID;
  [Column]
  public string City;
}

但是我觉得这是混合问题,它实际上将我的域层紧密耦合到Linq to SQL数据访问层.你同意吗？

假设我为域和数据访问层创建了两个"客户"类.假设City是必填字段.保存时,需要检查此规则.这应该在域层或数据访问层中完成,还是两者都完成？

谢谢,达伦

Answer 1

但是我觉得这是混合问题,它实际上将我的域层紧密耦合到Linq to SQL数据访问层.你同意吗？

是的,它会的.实体框架(代码优先)和nhibernate都可以使用单独的映射类,这将使您的模型清洁而不依赖于OR/M.

附注:域模型不应具有属性的公共setter(在DDD中).因为它有效地将模型逻辑移动到模型外部.

假设我为域和数据访问层创建了两个"客户"类.假设City是必填字段.保存时,需要检查此规则.这应该在域层或数据访问层中完成,还是两者都完成？

数据库实体应该只存在于存储库类中,因此不一定要验证它.正在保存的域模型应该已经具有正确的状态.

例:

public class ArticleRepository
{
    public void Save(Article article)
    {
        // Article is already in a correct state
        // (thanks to no public setters)

        var dbEntity = new ArticleEntity();
        Mapper.Map(article, dbEntity);
        _dbContext.Save(dbEntity);
    }
}

Answer 2

当然,这会将您的域层与DAL相结合.更糟糕的是,您的域层实体将具有与数据库中的表相同的结构.如果这些表是关系的,那么这将不是域模型的最佳表示.

我们所做的是让Linq-to-SQL实体存在于DAL中,然后我们在DAL中有映射类将L2S实体转换为域实体,反之亦然.这没关系,因为DAL确实是你的ORM,而它的一部分工作就是做这个映射.

我想说,如果City是必需的,那么作为业务规则,那就是业务逻辑,并且属于业务逻辑层中的业务规则.有一些验证包可以帮助解决这个问题.