CODEWITHSUNDEEP
asp.net-mvclinqlinq-to-sqlrepository-pattern
Derek Hunziker
Derek Hunziker

Reputation: 13141

Repository pattern: One repository class for each entity?

Say you have the following entities defined in a LINQ class:

Product
Customer
Category

Should I have one repository class for all:

StoreRepository

... or should I have:

ProductRepository
CustomerRepository
CategoryRepository

What are the pro & cons of each? In my case, I have several "applications" within my solution... the Store application is just one of them.

Upvotes: 27

Views: 7310

Answers (4)

Tien Do
Tien Do

Reputation: 11069

Basically there will be one repository per aggregate root object. There are some interesting points about DDD and aggregate root object and how we should design repository classes in the book ASP.NET MVC 2 in Action, look at it if you want to know more.

Upvotes: 1

James Fleming
James Fleming

Reputation: 2589

I'd have one repository/object because invariably, there'd need to be a map from my EntityTable to my domain object (such as in the body of the GetIQueryableCollection(). How I got around writing this repetitive code is by making a T4 template to generate it for me.

I have an example project which generates the repository pattern on codeplex http://t4tarantino.codeplex.com/ T4 Toolbox example Templates for business classes and repository. It may not work exactly the way you'd like without some tweaking, unless you're already implementing Tarintino and a few other goodies, but the templates are easy to configure. 

using System;
using System.Collections.Generic;
using System.Linq;
using Cses.Core.Domain.Model;
using StructureMap;

namespace Cses.Core.Domain
{
    /// <summary>
    /// Core class for Schedule E
    /// </summary>
    public class ScheduleERepository : IScheduleERepository
    {

        private Cses.Core.Repository.SqlDataContext _context = new Cses.Core.Repository.SqlDataContext();

        /// <summary>
        /// constructor
        /// </summary>
        public ScheduleERepository() { }

        /// <summary>
        /// constructor for testing
        /// </summary>
        /// <param name="context"></param>
        public ScheduleERepository(Cses.Core.Repository.SqlDataContext context)
        {
            _context = context;

        }

        /// <summary>
        /// returns collection of scheduleE values
        /// </summary>
        /// <returns></returns>
        public IQueryable<ScheduleE> GetIQueryableCollection()
        {           
            return from entity in _context.ScheduleEs                  
               select new ScheduleE()
               {    
                    Amount = entity.Amount,
                    NumberOfChildren = entity.NumberChildren,
                    EffectiveDate = entity.EffectiveDate,
                    MonthlyIncome = entity.MonthlyIncome,
                    ModifiedDate = entity.ModifiedDate,
                    ModifiedBy = entity.ModifiedBy,                      
                    Id = entity.Id                          
               };           
        }

Upvotes: 0

zowens
zowens

Reputation: 1566

Here's my point of view. I'm a strict follower of the Repository pattern. There should be 3 methods that take a single entity. Add, Update, Delete, generically defined.

public interface IRepository<T>
{
     void Add(T entity);
     void Update(T entity);
     void Delete(T entity);
}

Beyond those methods, you're dealing with a "Query" or a service method. If I were you, I'd make the repository genrically defined as above, add a "QueryProvider" as shown below and put your business logic where it belongs in either "Services" or in "Commands/Queries" (comes from CQRS, Google it).

public interface IQueryProvider<T>
{
     TResult Query<TResult>(Func<IQueryable<T>, TResult> query);
}

(Hope my opinion is somewhat useful :) )

Upvotes: 20

John Farrell
John Farrell

Reputation: 24754

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

Upvotes: 5

Related Questions