How do I handle table relationships with the repository pattern?

Question

I\'m implementing the repository pattern as part of an ASP.NET MVC site. Most examples I\'ve seen of repositories are fairly simple. For example here\'s a typical abstract repos

Answer 1

How does your app handle assigning a category to an item?

Does it:

1. Allows the user to view the item then assign it a category
2. Allows the user to view the category then add items to it

Let your app dictate which method you pick.

This brings up the idea of having a Business Logic/Services layer and dealing with aggregate roots. In my applications, I always have a services layer where all the business logic is at. I found that doing this has made my application easier to understand and maintain/refactor. (Note: I also use generic repositories and put the complex repository look ups in separate functions in the proper service class)

In your services layer, you'll have a function called AssignCategoryToItem which would then take the category (the aggregate root) and you would then add the item to that category and save the changes - although I would prefer passing in the IDs of the category and pulling it from the database before updating.

Answer 2

Once you have defined your aggregate roots you should create very specific repository interfaces (such as IProductRepository) for these, and have your service layer consume them.

Such as...

public interface IProductRepository
{
    IList<Product> GetProductsInCategory(Category c);
    Product GetProductBy(int id);
    IList<Category> GetActiveProductCategories();
}

Then in your concrete implementation of IProductRepository you would consume the generic repository and query your related entities and join them as required.