实体框架之领域驱动实践（五）：聚合

首先是“客户-信用卡”聚合,这个聚合表示了一个客户可以拥有多张信用卡,类似于上面所讲的“客户-送货地址”的概念;其次是“订单-订单行” 的聚合,类似地,虽然订单行也是一个实体,因为在应用中需要对每个订单行进行区分,但是订单行离开订单就变得毫无意义,它是“订单”概念的一部分;最后是 “产品分类-产品”的聚合.

每个聚合都有一个根实体(聚合根,Aggregate Root),这个根实体是聚合所表述的领域概念的主体,外部对象需要访问聚合内的实体时,只能通过聚合根进行访问,而不能直接访问.从技术角度考虑,聚合确定了实体生命周期的关注范围,即当某个实体被创建时,同时需要创建以其为根的整个聚合,而当持久化某个实体时,同样也需要持久化整个聚合.比如,在从外部持久化机制重建“客户”对象的同时,也需要将其所拥有的“信用卡”赋给“客户”实体(具体如何操作,根据需求而定).不要去关注聚合内实体的生命周期问题,如果你真的这么做了,那么你就需要考虑下你的设计是否合理.

由此引出了“领域对象生命周期”的问题,这个问题我会在后面两节单独讨论,但目前至少知道:

领域对象从无到有的创建,不是针对某个实体的,而是针对某个聚合的

领域对象的持久化(通常所说的“保存”)、重建(通常所说的“查询”)和销毁(通常所说的“删除”)也不是针对某个实体的,而是针对某个聚合的

很可惜,微软的Entity Framework(实体框架,EF)目前并不支持“聚合”的概念,所有的实体都被一股脑地塞到ObjectContext中: