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

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 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.