title: Real World ASP.NET MVC Repositories
body: <p>In the real world, Controllers can potentially need to use data from a variety of database tables and other data stores.  For example:</p>
  
  <pre><code>[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;
          }
  </code></pre>
  
  <p>So:</p>
  
  <ol>
  <li><p>Should I use a repository for each table?</p></li>
  <li><p>I guess this is where the concept of agregates comes into play?  Should I have one Repository per aggregate?</p></li>
  <li><p>Do I just add as many Repositories as I need to the constructor of the Controller?</p></li>
  <li><p>Is this a sign that my design is wrong?</p></li>
  </ol>
  
  <h2>NOTE:</h2>
  
  <p>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:</p>
  
  <pre><code>        Guid userId;
          public Guid UserId
          {
              get
              {
                  if (userId == null)
                  {
                      try
                      {
                          userId = (Guid) Membership.GetUser().ProviderUserKey;
                      }
                      catch { }
                  }
                  return userId;
              }
          }
  </code></pre>
  
  <p>One problem with that is surely caching this kind of output.  I can feel another question coming on.</p>
  
  <h2>EDIT:</h2>
  
  <p>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...</p>