Real World ASP.NET MVC Repositories

In the real world, Controllers can potentially need to use data from a variety of database tables and other data stores. For example:

[Authorize]
    public class MembersController : Controller
    {
        ICourseRepository repCourse;
        IUserCourseRepository repUserCourse;
        IMember member;
        public MembersController(ICourseRepository repCourse, IUserCourseRepository repUserCourse, IMember member)
        {
            this.repCourse = repCourse;
            this.repUserCourse = repUserCourse;
            this.member = member;
        }

So:

1. Should I use a repository for each table?

2. I guess this is where the concept of agregates comes into play? Should I have one Repository per aggregate?

3. Do I just add as many Repositories as I need to the constructor of the Controller?

4. Is this a sign that my design is wrong?

NOTE:

The IMember interface essentially represents a helper object that puts a nice face on the Membership provider. Ie, it puts all the code in one place. For example:

        Guid userId;
        public Guid UserId
        {
            get
            {
                if (userId == null)
                {
                    try
                    {
                        userId = (Guid) Membership.GetUser().ProviderUserKey;
                    }
                    catch { }
                }
                return userId;
            }
        }

One problem with that is surely caching this kind of output. I can feel another question comin开发者_Python百科g on.

EDIT:

I'm using Ninject for DI and am pretty sold on the whole DI, DDD and TDD thing. Well, sort of. I also try to be a pragmatist...

1. Should I use a repository for each table?

Probably not. If you have a repository per table, you are essentially doing Active Record. I also personally prefer to avoid calling these classes "Repository" because of the confusion that can occur between Domain Driven Design's concept of a "Repository" and the class-per-table "Repository" that seems to have become commonly used with Linq2SQL, SubSonic, etc. and many MVC tutorials.

2. I guess this is where the concept of agregates comes into play? Should I have one Repository per aggregate?

Yes and yes. If you are going to go this route.

'3.' Do I just add as many Repositories as I need to the constructor of the Controller?

I don't let my controllers touch my repositories directly. And I don't let my Views touch my domain classes directly, either.

Instead, my controllers have Query classes that are responsible for returning View Models. The Query classes reference whatever repositories (or other sources of data) they need to compile the View Model.

Well @awrigley, here is my advise:

Q: Should I use a repository for each table?

A: No, as you mentioned on question 2. use a repository per aggregate and perform the operations on aggregate root only.

Q: Do I just add as many Repositories as I need to the constructor of the Controller?

A: I guess you´re using IoC and constructor-injection, well, in this case, make sure you only pass real dependencies. this post may help you decide on this topic.

(pst! that empty catch is not a nice thing!!) ;)

Cheers!

This all depends on how "Domain Driven Design" your going to be. Do you know what an Aggregate Root is? Most of the time a generically typed repository that can do all your basic CRUD will suffice. Its only when you start having thick models with context and boundaries that this starts to matter.