绕过复杂查询的存储库模式可以吗？ [英] Is it okay to bypass the repository pattern for complex queries?
问题描述
这是我现在对DDD的理解：
This is my understanding about DDD at the moment:
- 严格的存储库模式只能实现get（），delete（）和create（），也可以是可以搜索或检索整个集合的get（）的变体。
- 每个聚合根具有一个存储库
（来自研究，我知道这些都不是普遍接受的规范）
(from research, I know those are not universally accept norms)
这里的问题是如何实现涉及许多聚合根的复杂查询。例如，我们有两个聚合根 - 产品和用户。如果我正在做一个页面，列出用户购买的产品，那么我有一个查询可以跨越用户聚合和产品聚合。
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.
应该如何查询执行？
-
我现在所做的是实际上是为这个查询和查询提供相关功能的资料库（有些将不同意说存储库不是查询层）。
What I am doing now is actually to have a repository for this query and queries with related functionality (some will disagree and say the repository is not a query layer).
仅使用产品和用户的存储库，获取所有记录，并在内存中执行所有操作（这听起来错误）
Use only the repository for product and user, grab all records and do everything in memory (this sounds wrong)
将查询（LINQ或SQL）置于服务内部，而不是使用与聚合相关联的存储库。
Have the query (LINQ or SQL) to be inside the service, not using the repository associated with the aggregates at all.
还有其他一些方法吗？
推荐答案
严格存储库模式应该仅实现get（），delete（）
和create（），也可以使用get（）的变体来搜索或
检索整个集合
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
存储库界面是您域的一部分，应基于无所不在的语言尽可能多。所有存储库都是不同的，就像所有的聚合都不同。严格的，通用存储库是CRUD过度通用，可能会降低代码表现力。 创建方法也不属于存储库，因为对象生命周期的开始通常由工厂或对象本身处理。 添加似乎是一个更好的名称，当你想保留现有的对象，因为存储库有收集语义。
Repository interface is part of your domain and should be based on Ubiquitous Language as much as possible. All Repositories are different just like all your Aggregates are different. Strict, generic repositories are CRUD overgeneralization and may reduce code expressiveness. 'Create' method also does not belong to Repository because beginning of object life cycle is usually handled by Factory or Object itself. 'Add' seems like a better name when you want to persist existing object because Repository has a collection semantics.
这里的问题是如何实现复杂的查询，涉及
许多聚合根。例如，我们有两个聚合根 -
产品和用户。如果我正在做一个页面，列出用户
已经购买的产品，那么我有一个查询可以跨越用户
聚合和产品聚合。
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.
在这种情况下，您只需听取业务需求，我强调了我认为最重要的部分。基于此，您需要：
In this case you just have to listen to the business requirements, I emphasized the part that I think is most important. Based on that it looks like you need:
Products products = /* get Products repository implementation */;
IList<Product> res = products.BoughtByUser(User user);
组织代码的想法是尽可能匹配业务需求和无处不在的语言。存储库接口的命名也很重要，我更喜欢使用产品或 AllProducts 而不是 ProductsRepository 。强烈推荐PhilCalçado对此主题有一个非常好的文章。 / p>
The idea of organizing code like that is to match business requirements and ubiquitous language as much as possible. The naming of the repository interfaces is also important, I prefer to have Products or AllProducts instead of ProductsRepository. Phil Calçado has a very good article on this subject, highly recommended.
How should this query be implemented?
该查询没有什么特别之处，它可以像Products库中的所有其他查询一样实现。查询本身是隐藏的，因为Repository 实现属于数据访问层。数据访问可以实现任何查询，因为它具有所有聚合及其关系的深入了解。在这一点上，它只是一个Hibernate或SQL问题。
There is nothing special about this query, it can be implemented just like all other queries in Products repository. The querying itself is hidden from Domain because Repository implementation belongs to Data Access layer. Data Access can implement any query because it has intimate knowledge of all the Aggregates and their relationships. At this point it would just be a Hibernate or SQL question.
这篇关于绕过复杂查询的存储库模式可以吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
