我通常会尝试将所有相关实体保存在同一个存储库中.以下是两者之间具有关系的实体(标有缩进):
用户
UserPreference
因此,进入用户存储库是有意义的.但是,用户通常会链接到许多不同的实体,您将在以下示例中执行哪些操作?
用户
UserPrefence
订购
订购
产品
订单与产品和用户都有关系,但您不会将所有4个实体的功能放在同一个存储库中.当您处理用户实体并收集订单信息时,您会怎么做?您可能需要有关产品的额外信息,并且ORM通常会提供延迟加载的功能.但是,如果您的产品实体位于用户实体的单独存储库中,那么这肯定会导致存储库之间发生冲突吗?
在Eric Evan的域驱动设计(http://domaindrivendesign.org/index.htm)中,你应该首先考虑一下你的Aggregates.然后,围绕这些构建存储库.
有许多技术可以处理彼此相关的聚合.我最常使用的那个是仅允许聚合通过只读接口相互关联.Aggregates背后的一个关键思想是,如果不通过root,就无法更改底层对象的状态.因此,如果产品和用户是模型中的根聚合,那么如果我通过用户 - >订单 - >产品进入产品,则无法更新产品.我必须从产品库中获取产品进行编辑.(从UI的角度来看,您可以看起来像用户 - >订单 - >产品,但是当您点击产品编辑屏幕时,您从产品库中获取实体).
当您从User-> Order-> Product查看产品(代码中)时,您应该查看无法更改产品基础状态的Product接口(仅获取任何设置等). )
根据您使用它们的方式组织您的聚合及其存储库.我可以看到User和Prodcut是他们自己的Aggregates并拥有自己的Repositories.我不能从您的描述中确定订单是属于用户还是独立.
无论哪种方式,当Aggregates关联时都使用readonly接口.当你必须从一个Aggregate交叉到另一个Aggregate时,从它自己的Repository中获取它.
如果您的存储库正在缓存,那么当您加载订单(通过用户)时,只从数据库加载产品ID.然后使用Product Id从Product Repository加载详细信息.您可以在加载订单时通过加载产品上的任何其他不变量来优化一点.