Asp.Net开发中 领域服务层和仓储层的疑惑

[weixin_40871647]

现在使用的框架中分了领域服务层和仓储层，并且使用到了ABP，目前遇到问题领域服务层和仓储层有些功能上的混淆

请教下这两层的使用区别以及关联。

目前遇到一个问题：比如现在有A,B两张表 ，业务逻辑是查寻A表中A1、A2以及B表中B1、B2一共四个字段，我是应该在A仓储层中查找A1、A2,在B仓储层中查找B1、B2 , 然后返回到领域服务层去进行数据处理吗？ 如果这样，仓储层返回的时候要新建两个类来分别包含A1、A2，B1、B2吗？
之前的简单都是做个视图直接数据库层面解决了，现在想想如果放在仓储层这个怎么弄呢？还是就不应该放在仓储层解决，而是放在 服务层去解决？

[圣殿骑士18]

只能这样了，这就是仓储模式的不方便。我是不用仓储模式的，甚至认为它是垃圾架构。

[西漠以西]

既然你都使用了领域服务和仓储这些DDD的概念，那么你考虑问题尤其是业务逻辑的问题时，应该从领域实体的角度来考虑，而不是动不动就想到数据表和字段，数据存储和查询的问题由仓储帮你搞定。 对于你说到的A和B两个表，我们假定它们分别映射为A和B两种领域对象的类型。那么接下来要搞清的是，它们是互有关联的两个实体对象类型，还是一个是实体类型另一个是值类型。先假设是前者吧 public class AEntity : Entity { public int A1 {get;set;} public string A2{get;set;} //others public BEntity B{ get;set;} } 那么仓储层查询加载AEntity实体对象时，ORM能自动加载它所包含的B对象，仓储会自动执行联接查询，或者当你访问A对象的B属性时，仓储帮你即时加载B属性所引用的BEntity实体对象，这叫延迟加载。 你只要让仓储为你返回AEntity就行了，这些事情仓储层的ORM帮你搞定。 没有必要专门设计一个类只包含A1A2B1B2，至少领域层不应该有这么个类，因为它明显不是个领域实体对象或者领域值对象。 如果你觉得某个地方真的需要只包含A1A2B1B2这几个属性的对象来承载数据，那么我猜应该是表示层（UI或者对外部的接口）中才需要，不过，这种对象应该是叫做DTO数据传输对象，它用来表示层和应用层之间传递数据，一般是由界面的需求而产生，但它不属于领域的范畴。