Looking for basic pointers on Repository Pattern for highly related entities

Question

I'm writing an database app in C# using SQL Server CR E 3.5 and would like to implement a Repository Pattern. I've done several searches both on Google and SO; however, I cannot find an implementation that matches my needs so I will ask the SO community directly.

The key business objects in my app are: video, actor, tag category and tag. The basic business rules are as follows:

1. Every tag belongs to a tag category.
2. A video may or may have not multiple actors and tags associated with it.
3. Actors and tags may or may not have multiple videos associated with them.

Here is where things get fuzzy for me:

1. Should I implement a video repository that includes actors, tag categories, and tags or should each of these business objects have their own repositories? Given these objects can exist independently, I'm inclined to create a repository for each one.

2. If each object should have its own repository, how do I relate them? For example, should the video repository include a property that queries the tag repository for matches?

I'm looking for some guidelines or best practices for setting this up. I understand the basics of the repository pattern, but I need some advice as to how to connect them together.

Answer 1

You should only have a repository for your aggregate roots.

I would not recommend using the repository as a way of encapsulating all your queries. Repositories are not big dumping grounds for queries - they are a specific tool for use in scenarios where DDD is most applicable. See this article for some more info: http://ayende.com/blog/3955/repository-is-the-new-singleton

There should be no need to 'connect' or 'relate' repositories.

If you want to write a query such as "Load all the tags for videos that this user has borrowed", it is probably best not to put it in the repository. This query is most likely specific to a certain case, e.g. a UI, and should be written inside or close to the class for which the query is required. The output of the query would probably be mapped to read-only Data Transfer Objects specifically created for the UI's requirement, not to your entities.