如果存储库用于聚合根，那么其他实体的数据访问逻辑应该放在哪里？
我有一些代表 Web 应用程序的对象。目前，我有一个集群对象来表示应用程序的特定部署。在集群对象中，我有以下对象：服务器、客户、用户。这些对象如果不是集群的一部分就不可能存在，因此我创建了一个 ClusterRepository 来从数据库中检索集群。现在，我需要从集群中获取客户列表，大概是通过使用 Cluster 对象中的方法（如 GetCustomers()）。现在，我最初的想法是将该操作的工作卸载到 CustomerRepository，但由于存储库仅用于聚合根，因此数据访问逻辑应该放在哪里？这属于服务类别吗？
I have a few objects that represent a web application. Currently I have a cluster object to represent a specific deployment of the app. Within a cluster object I have the following objects: Server, Customer, User. None of these objects can exist without being part of a cluster, so I created a ClusterRepository to retrieve the clusters from the database. Now, from the cluster I need to get a list of Customers, presumably by using a method in the Cluster object like GetCustomers(). Now, my initial thought was to then offload the work of this operation to a CustomerRepository, but since repositories are only for aggregate roots, where should the data access logic go? Does this belong in a service class?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
本质上，聚合根是您可能需要作为对象图的根来获取的任何对象。仅仅因为特定实体是聚合根并且具有存储库，并不意味着作为其属性之一的另一个实体也不能是聚合根 - 具有自己的存储库。
一个很好的例子是客户计费系统。 Customer 肯定是一个聚合根，并且包含发票的集合...但对于另一个应用程序功能，发票本身可能是一个聚合根，其对象图中包含组成 LineItem 对象。
因此，在您的示例中，如果您需要在某些情况下独立于集群来获取客户，那么为客户创建另一个存储库并没有什么问题。
注意：另请参阅评论中的线程。尽管根实体可以（并且经常会）引用其他根实体，但是不允许任何根实体的存储库包含管理（创建、更新）的功能（这可能是一个过于温和的措辞） ，或删除）其对象图中它所引用的任何根实体。任何此类引用的根实体都应该有自己的单独存储库，并且管理它们的功能（创建、更新和/或删除操作）应该位于它们的存储库中，以便它仅位于一个位置。
Essentially, an Aggregate root is any object that you might need to fetch as the root of an object graph. Just because a specific entity is an aggregate root, and has a repository, does not mean that another entity which is one of it's properties can't also be an aggregate root - with it's own repository.
A good example is a customer billing system. Customer would certainly be an aggregate root, and would contain a collection of invoices... But for another application function, the invoice itself might be an aggregate root with constituent LineItem objects in it's object graph.
So in your example, there is nothing wrong with creating another repository for customers, if you need to fetch them independantly of clusters in some situations.
NOTE: See thread in comments as well. Although root entities can, (and often will) have references to other root entities, it is frowned upon (and that may be too mild a turn of phrase) to allow the repository for any root entity to contain functionality that manages (creates, updates, or deletes) any root entity within its object graph that it has a reference to. Any such referenced root entities should have their own individual repositories, and the functionality to manage them (Create, Update and/or delete operations) should be in their repository, so that it is only in one place.