我正在构建一个ASP.NET MVC应用程序，我正在使用存储库来存储和检索视图对象。我的问题是，执行各种知识库可以相互调用吗？ I.E. ICustomerRepository实现是否可以调用IAddressRepository的实现，还是应该处理自己对地址数据源的更新？存储库模式问题
编辑：
谢谢大家，在客户/地址的例子是不是真实的。实际问题涉及三个集合，它们根据各自状态的变化更新第四个集合。我在这种情况下，似乎是引入依赖关系与违反不重复自己原则之间的冲突。
您应该为每个聚合根拥有一个存储库。
我没有你的域模型的知识，但感觉并不自然，让我有一个IAddressRepository。除非“地址”是您域中的聚合根。
事实上，在大多数情况下，“地址”甚至不是一个实体，而是一个值对象。也就是说，在大多数情况下，“地址”的标识由其值（所有属性的值）确定;它没有单独的“Id”（键）字段。
因此，在这种情况下，CustomerRepository应负责存储地址，因为Address是客户聚合根的一部分。
编辑（确定，所以你的情况只是一个例子）：
但是，如果你有，你就需要在资源库中另一个仓库等情况，那么我认为这是更好地去除功能从该存储库中取出，并放入一个单独的类（Service）中。 我的意思是：我认为，如果你有一个仓库A内的一些功能，它依赖于另一个仓库B，那么这种功能并不库A内属于
相反，写另一个类（这被称为在DDD服务），在你实现这个功能的地方。
无论如何，我不认为库中，应当真正相互调用。但是，如果您不想编写服务，并且您确实希望将该逻辑保存在存储库本身中，则可以将该另一个存储库作为参数传递给该特定方法。
我希望我自己有点清楚。 ：P
他们真的不应该互相打电话。存储库是您想要在您的域上执行的（或多或少）原子操作的抽象。他们拥有的依赖性越小越好。实际上，存储库的任何使用者都应该期望能够将存储库类指向数据库，并让它在没有大量配置的情况下执行必要的域操作。
他们也应该代表了你的域“集合” - ，很多功能会根据周围即关键焦点。我想知道为什么你会有一个单独的地址信息库？这不应该成为您的客户存储库的一部分吗？
这只是一个简单的例子。实际模型是一个相当复杂的库存系统，存在多个以多个现有集合为中心的接口，用户可以通过这些集合修改相同的库存数据，这反过来也是它自己的（有限）直接修改的集合。 – Paul 2009-09-01 22:14:18
这取决于库的类型（或至少后果做），但一般来说，如果你有数据仓库称呼对方你会遇到这样的周期性（回购A和事情的问题 - >要求B - >需要C - 。oops，需要A）或递归数据加载（A->需要B & C - > C-需要D，E - > .... - > ..附加说明）。测试也变得更加困难。
例如，您需要加载地址存储库以正确运行客户存储库，因为客户存储库调用地址存储库。如果您需要测试客户回购协议，则需要对地址执行数据库加载或以某种方式对它们进行模拟，最终，您将无法加载和测试任何单个系统存储库，而无需全部加载它们。
有那些依赖关系也是一种阴险的，因为他们往往不明确的 - 通常你正在处理一个存储库作为数据保持抽象 - 如果你必须要意识到他们是如何互相依赖，你可以不会将它们用作抽象，但是只要您想使用它们，就必须管理加载过程。
谢谢，服务类应该做的伎俩。 – Paul 2009-09-01 22:36:25