设计模式 – 绕过复杂查询的存储库模式可以吗?

前端之家收集整理的这篇文章主要介绍了设计模式 – 绕过复杂查询的存储库模式可以吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
这是我现在对DDD的理解:

>严格的存储库模式应该仅实现get(),delete()和create(),也可以是get()的变体,可以搜索或检索整个集合
>每个聚合根共有一个存储库是常见的

(从研究,我知道那些不是普遍接受的规范)

这里的问题是如何实现涉及许多聚合根的复杂查询.例如,我们有两个聚合根 – 产品和用户.如果我正在做一个页面,其中列出了用户购买的产品,那么我有一个查询可以跨越用户聚合和产品聚合.

查询应该如何实现?

>我现在所做的是实际上是为这个查询查询提供相关功能的存储库(有些将不同意,并且说存储库不是一个查询层).
>仅使用产品和用户的存储库,抓取所有记录,并在内存中执行所有操作(这听起来错误)
>将查询(LINQ或sql)放在服务内部,而不是使用与聚合相关联的存储库.

还有其他一些方法吗?

@H_403_18@解决方法

The strict repository pattern should only implement get(),delete()
and create(),and maybe variants of get() where one can search or to
retrieve an entire collection

存储库界面是您的域的一部分,应尽可能基于Ubiquitous Language.所有存储库都是不同的,就像所有的聚合都不同.严格,generic repositories是CRUD过度概括,可能会降低代码表现力. “创建”方法也不属于存储库,因为对象生命周期的开始通常由工厂或对象本身处理.当您想要存储现有对象时,“添加”似乎是一个更好的名称,因为Repository具有集合语义.

The question here is how to implement complex queries which involves
many aggregate roots. For example,we have two aggregate roots –
product and user. If I am doing a page which list what products a user
have bought
,then I have a query which stretch across both the user
aggregate and the product aggregate.

在这种情况下,您只需听取业务需求,我强调了我认为最重要的部分.基于此,您需要:

Products products = /* get Products repository implementation */;
IList<Product> res = products.BoughtByUser(User user);

组织这样的代码的想法是尽可能地满足业务需求和普遍存在的语言.存储库接口的命名也很重要,我更喜欢使用Products或AllProducts而不是ProductRepository. PhilCalçado有一个very good article这个问题,强烈推荐.

How should this query be implemented?

这个查询没有什么特别之处,它可以像Products库中的所有其他查询一样被实现.查询本身是隐藏的,因为存储库实现属于数据访问层.数据访问可以实现任何查询,因为它具有所有聚合及其关系的深入了解.在这一点上,它只是一个Hibernate或sql问题.

原文链接:https://www.f2er.com/html/231230.html

猜你在找的HTML相关文章