C# 以下哪一种是存储库模式？

我的域实体像树一样排列：

根
-儿童1
--儿童1.1
--儿童1.2
-儿童2
--儿童2.1
--儿童2.2

最后，我们就如何围绕这些域对象设计存储库提出了两个（相当强烈的）意见：

意见一：
我需要2个存储库Child1Repository&Child2Repository，它由RootFacade/RootManager类管理，以调用存储库上的适当方法。当RootFacade是BLL时，这两个子存储库仅处理DAL操作。RootFacade向应用程序公开DTO，而在内部所有3个存储库都使用域对象

意见二：
我需要1个存储库RootRepository来处理一切（BLL+DAL）。存储库在内部处理域对象时公开DTO

我想对这两点有一些看法&这确实是存储库实现的方法

---

感谢所有的帮助，

类不应该承担比他们需要承担的更多的责任，而且听起来

根存储库的方法显然是错误的。它吸收了太多的复杂性，并负责太多的实体。在您介绍的两个选项中，第一个是更好的选择：拥有更多的存储库，每个存储库负责自己的领域

然而，也就是说，我不清楚为什么您有一个
RootManager
。我更希望有一系列
DomainObjectRepositories
，它们各自在内部管理自己的业务逻辑，只公开相关的公共操作，然后将实际的数据库操作推迟到数据访问对象
DomainObjectDao
。拥有一个无所不知的全业务逻辑类是一种可怕的代码气味，在这种特殊情况下有点企业化的过度使用。
我们使用选项1，它非常适合我们。假设子1是用户存储库，子2是角色存储库，facade是安全facade。用户存储库将返回作为聚合根的用户域对象，并且用户对象包含角色。我们实际上只会将角色存储库用于GetAllRoles

我们的域对象有一个GetDTO方法，该方法返回DTO以供facade传输

我希望这会有所帮助。
只是想澄清一下——这是一种物理继承，比如管理者和下属，还是一种子类型为派生类型的类继承？根是各种子元素的容器。根-子元素之间没有物理继承，但对所有子元素都有树继承。没有根，子类型不能存在。虽然根-子组合之间没有物理继承，但根是各种子项集合的容器。子项可以是树集合。因此，即使我有各种ChildRepository实现，它也总是需要根上下文才能执行任何操作。此外，业务规则是在根级别定义的&因此问题是我是否需要跨存储库调用来验证我的规则（因此需要RootFacade/Manager类）啊，我明白了；从你最初的问题看不清楚。然而，我仍然认为我的答案是：如果没有
图书馆
，一本
书
是不可能存在的，但是你可能仍然想对
书
执行一些与
图书馆
无关的操作（例如，在镇上的任何图书馆中查找一本书，而不仅仅是某个特定图书馆的藏书）。至于跨多个存储库调用，如果这两个存储库已经彼此有某种关联，那么这也没关系。一个存储库问另一个存储库一个问题并没有本质上的错误。我喜欢你们的图书馆图书示例，因为这是我的实体排列方式。我的案例的关键区别在于，所有操作都是在库上进行的，如：library.AddBook（）、library.IssueBook（）等。在我的案例中，该书不能有自己的操作。没有多个库场景。如果确实如此，那么我同意您的特定案例不需要BookRepository来公开自己。但在我看来，由一个无所不知的实体管理这么多对象仍然是错误的。我很难相信这是设计东西的最佳方式（当然，不知道您的具体情况）。因此，在这种情况下，UserRepository将处理如下规则：如果用户处于角色“a”，则不能为其分配角色“b”RoleRepository只执行DAL操作。我的理解正确吗？不，这是域对象处理业务逻辑的责任。查看类似这样的规范模式。任何存储库都不应包含任何业务逻辑。