|
|
1
5
在Eric Evan的领域驱动设计中( http://domaindrivendesign.org/index.htm )你应该首先考虑一下你的聚合是什么。然后,您围绕这些构建存储库。 有许多处理相互关联的聚合的技术。我最常用的方法是只允许聚合通过只读接口相互关联。Aggregates背后的一个关键思想是,如果不经过根,就无法更改底层对象的状态。因此,如果产品和用户是模型中的根聚合,那么如果我通过用户访问产品,我就无法更新产品。>订单->产品。我必须从产品存储库中获取产品才能对其进行编辑。(从UI的角度来看,你可以让它看起来像是用户->订单->产品,但当你点击产品编辑屏幕时,你会从产品存储库中抓取实体)。 当您从“用户”->“代码”查看产品时;订单->您应该查看的产品界面没有任何方法可以更改产品的底层状态(只有没有设置等) 按使用方式组织聚合及其存储库。我可以看到User和Prodcut是他们自己的聚合,并拥有自己的存储库。从你的描述中,我不确定订单是属于用户还是独立的。 无论哪种方式,当聚合相关时,都使用只读接口。当您必须从一个聚合交叉到另一个聚合时,请从它自己的存储库中获取它。 如果您的存储库正在缓存,那么当您(通过用户)加载订单时,只会从数据库中加载产品Id。然后使用产品Id从产品库加载详细信息。您可以在加载订单时通过在产品上加载任何其他不变量来进行优化。 |
|
|
2
1
你说的存储库是指类吗? 根据对象(存储库)的使用情况,您可以创建一个视图,将数据库上的数据组合在一起,并使用ORM创建一个类(存储库”)来表示该视图。当您想显示每个表中只有几列的较轻重量的对象时,这种设计是可行的。 |
|
|
3
0
如果SQL Server是您的数据库,而您所说的存储库是指数据库,那么我只会将信息粘贴在任何有意义的数据库中,并在依赖数据库中查看,通过三点表示法从其他数据库中选择。 |
|
|
4
0
我仍然对你所说的“存储库”的意思感到困惑。我会把你提到的所有东西都做成单独的类(因此是单独的文件),它们都驻留在同一个项目中。 |