Organizing classes using the repository design pattern

Question

I have started upgrading one of our internal software applications, written in ASP.NET Web Forms, and moving to ASP.NET MVC.

I am trying to leverage the Repository design pattern for my classes, which leads me to my question about how much to put into a repository.

I have the following entities:

• Topic
• Topic Comments (Topic can have multiple comments)
• Topic Revisions (Any time a Topic is edited, a revision is recorded)
• Topic Subscriptions (Allows users to subscribe to changes for a particular Topic)

I currently have an interface for ITopicRepository and a class called TopicRepository that handles all the basic CRUD for a Topic. I am now preparing to add code for the Comments, Revisions and Subscriptions.

I am wondering does ALL this go into the TopicRepository OR do I create a repository for each of the entities, for example, TopicRevisionRepository and so on.

Answer 1

In my opinion it should go into it's own repository...

Edit:

Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

Repository Pattern

This allows if your interested to use a generic repository like this example which means less code...

Answer 2

Looking at the NerdDinner tutorial, they seem to go with a respository per entity.

When you think about it, it makes sense. There are going to be cases where you want to have control over when to load sub-entities.

Answer 3

There's a pretty substantial disconnect between the average MVC data access strategy and the Domain-Driven-Design understanding of the repository pattern.

Most of the samples you'll see for ASP.Net MVC are just a slight step beyond ActiveRecord, using Repository objects per entity. What they're actually implementing is kind of a Table Data Gateway, and using the word Repository instead of Gateway.

There's nothing wrong with that for many applications, and I've generally started new applications with the same approach until I can prove I need something different. However, Domain Driven Design principles, from which the idea of the repository is generally borrowed, would have you identify Aggregate Roots and consolidate data access for those child entities through the aggregate root's repository. This allows you to put boundaries around state changes in your data store, and can help enforce transactional changes, among other things.

Edited to add: In your example, it seems highly unlikely that you'd modify any of these child objects in isolation from the parent, so I'd be tempted to say that a "topic" is an aggregate root for your domain.

Answer 4

I think it depends on how your going to access your data. Changes are your always going to look at a topic with its comments and vice versa for like ( 32 ) Comments UI elements.

Therefore your topic becomes an Aggregate Root and you only need a single repository for this approach.

One thing to consider is if you have many small things you only need very narrow access to like a list of options for a dropdown you really don't want a full blown repository for that. The problem becomes that once you pass 20 entities you'll end up having 20 interfaces and 20 repositories to think about in your solution.

Its very pragmatic to only have repositories for your aggregate roots and keep other value type repositories together. For example a DropdownlistRepository or something.

Finally your at the stage of your project were performance concerns just don't matter and retrieving an entire object graph for the "Topic" probably isn't that bad performance wise. Keep things simple, if you using a ORM mapper it should be able to handle giving you the Topic every time you need it with all its child entities lazily loaded.