存储库模式和多个相关的核心实体或业务对象 - 一个或多个存储库？

Question

我正在考虑实现存储库模式（因为无论如何，我想出的 90% 都是它的实现），并且遇到了一个设计问题 - 我有两个或多个核心业务对象（例如，业务和联系人） CRM 应用程序），BO 可以是强相关的，也可以是根本不相关的。

在这种情况下，我应该实现一个存储库（例如 CrmRepository，带有 .addBusiness()、.addContact() 等）还是多个存储库（BusinessRepository、ContactRepository，每个存储库都有自己的 .add()、.delete() 等） ）。

在这种情况下，最佳做法是什么？

底层 DAL 是 EF4。

问候

穆

Answer 1

最近，我们在工作中进行了很多思考，并发现了一些文章，帮助我们以一致的方式可视化和设计我们的存储库。

根据我们的发现，更好的做法之一是为每个聚合根创建一个存储库。聚合根将是一个实体类型，您需要引用该实体类型才能访问子值类型。只能从数据库查询实体类型，并且需要从实体遍历任何子值类型。

根据您问题中的信息，业务似乎是一个聚合根，因此是一个实体类型，并且需要自己的存储库。由于联系人可以独立存在，因此也可能是聚合根。两个对象可以相互引用，并使用存储库从联系人加载业务或通过其各自的存储库从业务加载联系人。

我最近读了很多书，所以我希望我的思考过程有意义。

一些链接

聚合根

实体、值对象、聚合和根

Answer 2

我完全同意马克的观点，但还要补充一点。当您了解创建通用存储库的好处时，常见的模式是 IRepository 和 Repository。我发现更有用的一件事是 Jeremy D. Miller（找不到参考资料）指出的，那就是在方法级别使用泛型。

所以我的 IReposity 将具有这样的方法：

T FindByKey<T>(int key);
IEnumerable<T> FindAll();
T FindBy<T>(System.Linq.Expressions.Expression<Func<T, bool>> expression);
void Update<T>(entity);

然后，根据您的理念，您可以传递 Repository 类并直接查询它，或者使您的 Repository 实现抽象并强制它被显式存储库封装，如下所示：

CrmRepository : Repository
{
   FindByCustomerId(int customerId)
   { return FindByKey<Customer>(customerId);}
}