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

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)

我应该只有身份证号码吗？
产品类别中的类别和用途
一个单独的产品存储库
类别来加载类别？

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

2)

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

不确定这到底是什么意思。 （我想看看你是如何做到这一点的代码片段。）但我的猜测是，在你的派生 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 是分别是产品或类别）。

我会避免在这些存储库之间进行引用，因为每当您添加新实体或导航属性时，这可能会导致大量复杂的存储库引用。

我看到另外两个选项：

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

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

  公共类 ProductProxy ：产品
  {
      私有 IUnitOfWork _unitOfWork；
  
      公共 ProductProxy(IUnitOfWork 工作单元)
      {
          _工作单元 = 工作单元；
      }  
  
      公共类别 类别
      {
          得到
          {
              // ...
              var ProductRepo = _unitOfWork.CreateGenericRepo();
              varcategoryRepo = _unitOfWork.CreateGenericRepo<类别>();
              // 你可以取出你需要的存储库并使用它们
          }
          放 { ... }
      }
  }
  

我更喜欢第二个选项，因为在第一个选项中您可能最终会得到在巨大的存储库支持加载所有可能的关系。想想：订单有订单项目，订单项目有产品，产品有类别，订单有客户，客户有地址列表，地址有联系人列表等等......

4) (因为您也在寻求批评）

您是在编写自己的 ORM 还是在编写应用程序？你的设计走向了一个可能变得非常复杂的方向，在我看来，你正在重新发明轮子。如果您计划使用 EF 或 NHibernate（或其他 ORM），那么您正在创建已经可用的开箱即用的函数，您只需将抽象放在其上，这不会增加任何价值。通过动态代理进行延迟加载是透明的，因为您从不明确地使用代码中的这些代理，而始终使用 POCO 实体。它们是不可见的并且仅在运行时存在。为什么要开发自己的延迟加载基础设施？

Answer 2

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

我个人认为将成员标记为virtual对于延迟加载功能来说是一个很小的代价

Answer 3

我正在做一些非常相似的事情，就我而言，我有产品和产品类别的存储库。存储库外部没有人知道内容是如何加载的 - 惰性加载或其他任何加载 - 因此您可以稍后根据需要进行更改。就我而言，我急切地加载类别，因为它们的访问量如此之大，并且我按需加载产品并将它们缓存一个小时左右。

Answer 4

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

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

一般来说，这意味着您只需将我们的数据库模式直接暴露给整个应用程序，并在其顶部覆盖一层非常薄的“模型”。

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

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

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

尝试将所有这些不同的用途组合成一个契约或接口，或多或少会导致上帝对象实体。

您只需要该类别集合来进行某些显示和某些操作。试图一直暴露它只会导致疼痛。