c# - 存储库模式 : Implementation and lazy loading of model relationships

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，并使用单独的产品类别存储库来加载类别？

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

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

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

你会采取什么方法？(欢迎任何建议和批评)

---

我应该指出，我希望应用程序是可扩展的，并且存储库和模型本身的所有接口(interface)都将在一个单独的组件中。这意味着扩展程序将无法直接访问模型类定义。

Answer 1

一些评论和我的看法:

1)

Should I have only the ID of the category in the Product class and use a separate repository for product categories to load the category ?

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

2)

For now my implementation of the repository interface returns an object of a type which extends the Product type and has support for lazy-loading through the repository instance.

不确定这到底是什么意思。 (我想看看你是怎么做到的代码片段。)但我的猜测是，在你派生的 Product 中您以某种方式注入(inject)对存储库的引用的类，如下所示:

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)

I'm interested in how the product and category repositories should interact to achieve the lazy-loading ? Should they reference each other or should I have a main repository with the two sub repositories and pass that to my extended model types ?

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

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

我看到另外两个选项:

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

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

  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 { ... }
      }
  }
  

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

4)(因为你也在求批评)

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