与存储库模式分离关注点

时间:2011-07-22 23:08:36

标签: design-patterns database-design repository repository-pattern separation-of-concerns

我对存储库访问的位置有疑问。在存储库维护的实体中允许或包含存储库访问是否可以接受?

例如:

class Product
{
    public int ProductID {get;set;}
    public int Name {get;set;}
    public IList<Product> Products {get;set;} // A Product may be a bulk item that contains several individual items.
    public int VendorID {get;set;} // Key to another table that list vendor info.
}

public class ProductRepository : IRepository
{
   public Product GetProduct(int id) {}
   public IList<Product> GetProducts() {}
}

几个问题:

  1. 应该从哪个位置检索其他表中的信息?存储库,服务,实体等。这是否也适用于批量项目的包含产品?
  2. 何时会发生这种情况,在检索产品时,或者是否/何时访问供应商/子产品?

1 个答案:

答案 0 :(得分:1)

我建议调查ORM(对象关系映射器)处理这类问题的方式;一般来说,它们处理它的方式是存储库根据需要管理所有序列化/反序列化;有一些相对复杂的逻辑继续反序列化树中的元素(延迟加载等)。 ORM空间已经考虑了许多这些问题,并且有一些解决方案可以考虑每个潜在解决方案的彻底细节,因此这是适当的地方。作为一个起点,考虑一下Hibernate如何发挥其魔力;它是一种广泛使用的ORM,具有非常好的设计。

特别是,我强烈建议不要试图自己实施这类东西;考虑使用ORM(同样,Hibernate来自我和其他人的高度推荐)来处理这个过程的细节;他们已经解决了这些问题中出现的许多问题。