Question

I have a question regarding location of repository access. Is it acceptable practice to allow or contain Repository access within an Entity that the Repository Maintains?

For example:

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() {}
}

A Few Questions:

1. Where should retrieval of information from other tables be located? Repository, Services, Entity etc.. Would this also apply to the Contained Products for bulk Items?
2. When should this occur, At the time the product is retrieved, or if/when the Vendor/SubProduct accessed?

Answer 1

I’d recommend looking into the way ORMs (Object Relational Mappers) handle this sort of issue; in general, the way they handle it is that the repository manages all serialization / deserialziation as needed; there’s some relatively complex logic that goes on for deserializing the elements in a tree (lazy-loading and the like). The ORM space has considered many of these issues, and there are solutions that consider the thorough ins and outs of each of the potential solutions, so that’s the appropriate place to look. As a starting point, consider looking into how Hibernate does its magic; it’s a widely used ORM that has a pretty good design.

In particular, I’d strongly advise against trying to implement this sort of stuff yourself; look into using an ORM (again, Hibernate comes highly recommeded, from me and from others) to handle the specifics of this process; they’ve worked through many of the issues that come up in doing this stuff.