浴室沉思：聊聊DAL和Repository - Mutuduxf's Blog

[Mutuduxf]

https://www.mutuduxf.com/2018/01/20/%E6%B5%B4%E5%AE%A4%E6%B2%89%E6%80%9D-%E8%81%8A%E8%81%8ADAL%E5%92%8CRepository.html

这是一个由DDD群引发的随笔在写了上一篇随笔《关于ORM的浴室沉思》后一些朋友私聊我，很多刚接触DDD的朋友会对Repository（仓储层）这东西有点疑惑，为什么要叫仓储层？是不是三层的DAL换个名字而已？毕竟大家都是对数据库的操作嘛，而且我用EF还有必要用仓储么？是不是可以省掉这一层？ABP框架的持久化究竟有...

[zm1987]

aaaaaa

[jonechenug]

enum 居然用系统自带的，不够ddd啊。应该换成实体类，参考微软搞得那个购物车实例，直接用类的好处是可以直接存储到数据库，也可以在代码里面映射，只要值一样就认为相等。比直接用enum好用。另外说一句，大多数人还停留在怎么快怎么来，所以能做到解耦就不错了，iqueryable 并不算多大问题，毕竟支持很多种orm驱动（nosql也支持），问题更大的是虽然用着仓储，但是直接在业务层写sql！

[Mutuduxf]

enum用语言自带的没问题，因为持久化是PO的职责，在领域层中可以充分地使用语言特性来提高代码的可读性。至于IQueryable我们这边的规范是只能出现在Repository/QueryService，领域层甚至应用层出现IQueryable天知道会写出什么幺蛾子。

[jonechenug]

虽然语言自带了enum，但不是所有orm都支持。可以看看Enumeration，枚举用这个会更ddd

[Mutuduxf]

@jonechenug 虽然语言自带了enum，但不是所有orm都支持。可以看看Enumeration，枚举用这个会更ddd

ORM实际上属于持久化的技术选型，领域层的东西不应该反过来被某些技术选型影响，这也是为什么有了ORM但依然有仓储层的原因。而且有了仓储层后ORM实际上服务的是PO而不是DO，因此对于仓储层来说，ORM反而不是必须的。

[jonechenug]

你误会我的意思了，我的意思是专门搞个类来干枚举的事，比单纯用枚举好用多了（也更面向对象），和ORM无关。不知道你有没有遇到过这种情况，在DTO中并不需要传输该枚举的全部字段，而额外搞个枚举又需要去强转。而这个是基于值对象去匹配的，只要值相同，就认为是一样的枚举。

[Mutuduxf]

@jonechenug 你误会我的意思了，我的意思是专门搞个类来干枚举的事，比单纯用枚举好用多了（也更面向对象），和ORM无关。不知道你有没有遇到过这种情况，在DTO中并不需要传输该枚举的全部字段，而额外搞个枚举又需要去强转。而这个是基于值对象去匹配的，只要值相同，就认为是一样的枚举。

使用Class不代表就是更面向对象的。领域层的设计是最核心的部分，不应该为了其它技术实现或者层而进行妥协，而是应该反过来。至于DTO不传输枚举的全部字段，那应该在DTO的Converter进行处理，至于DTO怎么设计其实和领域层是毫无关系的。

[CwjXFH]

看文中，多个类型放到一起就是一个聚合，就可以使用仓储对其进行持久化操作

[Mutuduxf]

@CwjXFH 看文中，多个类型放到一起就是一个聚合，就可以使用仓储对其进行持久化操作

聚合说简单不简单说难也不难，其实就一句话：依据业务的不变性划分的最小业务单元，在权衡开发成本的前提下尽量设计得小一点。 所以很多刚接触DDD的人以为存在主外键就是聚合，这是错的。