存储库模式：模型关系的实现和延迟加载

Question

我有一个处理产品和产品类别的应用程序。 对于每一个，我都有使用POCO定义的模型。

// Represents a product.
class Product {
  public virtual int ID { get; set; }
  public virtual string Name { get; set; }
  public virtual ProductCategory Category { get; set; }
}

// Represents a product category.
class ProductCategory {
  public virtual int ID { get; set; }
  public virtual string Name { get; set; }
  public virtual IEnumerable<Product> Products { get; set; }
}

该应用程序使用存储库来访问这些模型

// The interface implemented by the application's repository
interface IProductRepository {
  IEnumerable<Product> GetAllProducts();

  void Add(Product product);
  void Remove(Product product);
  void Save(Product product);
}

在Product类中，仅在需要/访问（延迟加载）时才应加载名为ProductCategory类型的Category属性。 我希望我的模型保持POCO并仅包含模型的结构。

我采取正确的方法吗？
我是否应该仅在Product类中具有类别的ID，并为产品类别使用单独的存储库来加载类别？

实现延迟加载和关系
现在，我对存储库接口的实现返回一个类型的对象，该对象扩展了Product类型，并支持通过存储库实例的延迟加载。

谁应该负责加载产品类别？

我对产品和类别存储库应该如何交互以实现延迟加载感兴趣？ 他们应该互相引用还是我应该拥有一个带有两个子存储库的主存储库，并将其传递给我的扩展模型类型？

您会采取什么方法？ （欢迎提出任何建议和批评）

---

我应该注意，我希望应用程序是可扩展的，并且存储库和模型本身的所有接口都将放在单独的程序集中。 这意味着扩展程序将无法直接访问模型类定义。

Answer 1

一些评论和我的看法：

1）

我是否应该仅在Product类中具有类别的ID，并为产品类别使用单独的存储库来加载类别？

否。您正在使用ORM（至少我假设您这样做），以便能够通过类实例之间的引用而不是通过您随后使用的ID以关系方式进行查询来对关系进行建模。 将您的想法带到最后一个结果将意味着您从模型类中完全删除了所有导航属性，并且仅具有标量属性，其中一些充当对象之间的键。 那只是ORM中的“ R”。

2）

现在，我对存储库接口的实现返回一个类型的对象，该对象扩展了Product类型，并支持通过存储库实例的延迟加载。

不知道这到底意味着什么。 （我想看一个代码片段如何做到的。）但是我的猜测是，在派生的Product类中，您以某种方式注入了对存储库的引用，如下所示：

public class ProductProxy : Product
{
    private IProductRepository _productRepo;

    public ProductProxy(IProductRepository productRepo)
    {
        _productRepo = productRepo;
    }

    // now you use _productRepo to lazily load something on request, do you?
}

好吧，现在加载类别显然是一个问题，因为IProductRepository没有访问它们的方法。

3）

我对产品和类别存储库应该如何交互以实现延迟加载感兴趣？ 他们应该互相引用还是我应该拥有一个带有两个子存储库的主存储库，并将其传递给我的扩展模型类型？

您的ProductRepository和CategoryRepository看起来像是仅负责单一实体类型的通用存储库的实例（在EF 4.1中，这类似于DbSet<T> ，其中T分别是Product或Category 。）

我会避免在这些存储库之间使用引用，因为每当您添加新的实体或导航属性时，这最终都会导致复杂的存储库引用。

我看到另外两个选择：

• （基本上就是您已经提到的内容）拥有一个负责Product和Category的存储库。 您仍然可以拥有通用存储库，但我将它们更多地视为内部帮助存储库，并且仅将它们用作主存储库中的私有成员。 这样，您可以拥有一组存储库，每个存储库负责一些紧密相关的实体。

• 引入一个能够创建所有通用存储库Unit of Work （同样在EF 4.1中，这类似于工厂方法DbContext.Set<T>() ，其中DbContext是工作单元），然后将其注入研究您的派生实例：

   public class ProductProxy : Product { private IUnitOfWork _unitOfWork; public ProductProxy(IUnitOfWork unitOfWork) { _unitOfWork = unitOfWork; } public Category Category { get { // ... var productRepo = _unitOfWork.CreateGenericRepo<Product>(); var categoryRepo = _unitOfWork.CreateGenericRepo<Category>(); // you can pull out the repos you need and work with them } set { ... } } } 

我更喜欢第二种选择，因为在第一种选择中，您可能最终会存储在庞大的存储库中，以支持所有可能关系的加载。 可以想到：订单具有OrderItems，OrderItem具有产品，产品具有类别，订单具有客户，客户具有地址列表，地址具有联系人列表等等，依此类推...

4） （因为您还要求批评）

您是在编写自己的ORM还是在编写应用程序？ 我认为您的设计朝着一个可能变得非常复杂的方向发展，并且您正在重新发明轮子。 如果您打算使用EF或NHibernate（或其他ORM），那么您将创建开箱即用的功能，只需将抽象放在其上即可，不增加任何价值。 通过动态代理进行的延迟加载是透明地进行的，这意味着您永远不会在代码中显式地使用这些代理，而始终使用POCO实体。 它们是不可见的，仅在运行时存在。 您为什么要开发自己的惰性加载基础结构？

Answer 2

NHibernate支持通过代理对象进行延迟加载（默认情况下使用Castle DynamicProxy ），该代理对象将由存储库操纵的类子类化。 NHibernate要求您将成员标记为virtual成员以支持此方案。 我不确定什么组件在需要时启动加载调用，但怀疑它是代理实例。

我个人认为将成员标记为virtual是懒加载功能的一个小代价。

Answer 3

我正在做非常相似的事情，就我而言，我有产品和产品类别的存储库。 信息库之外的人都不知道事物的加载方式（惰性或其他），因此以后可以根据需要进行更改。 就我而言，由于他们访问量很大，所以我急切地加载类别，然后按需加载产品并将其缓存一个小时左右。

Answer 4

我希望我的模型保持POCO并仅包含模型的结构。

我会问，为什么数据的形状对这些类很重要？

通常，这意味着您只是将我们的数据库模式直接公开给整个应用程序，并在其顶部非常薄的“模型”外框。

我建议实体包含的数据是私有的，应该封装，并且行为应该是实体的重点。

此外，一次加载所有需要的数据更加简单明了。 如果潜在数据量太多，那么我建议您将太多职责分配给一个实体，您将需要进一步优化模型或添加一种机制来根据您所处的上下文来检索实体使用它。

我的意思是，如果要查询显示数据，则需要公开一些数据。 您可以在另一个上下文中查询相似但不同的数据集。 更进一步，如果您需要执行操作或修改，则您的实体需要公开特定的行为。 但是在不同的上下文中-当您检索实体以执行不同的操作或修改时，则需要公开其他不同的特定行为。

试图将所有这些不同的用途组合到一个合同或接口中，或多或少会导致上帝对象实体的出现。

对于某些显示和某些操作，您只需要类别的集合即可。 试图使其一直暴露在外只会引起痛苦。