Click here to Skip to main content
Click here to Skip to main content

Repository pattern, done right

, 13 Jan 2013
Rate this:
Please Sign up or sign in to vote.
This post aims to explain why the Repository Pattern is still a great choice.

The repository pattern has been discussed a lot lately. Especially about its usefulness since the introduction of OR/M libraries. This post (which is the third in a series about the data layer) aims to explain why it’s still a great choice.

Let’s start with the definition:

A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes

The repository pattern is used to create an abstraction between your domain and data layer. That is, when you use the repository you should not have to have any knowledge about the underlying data source or the data layer (i.e. Entity Framework, nhibernate or similar).

Why do we need it?

Read the abstractions part of my data layer article.

Implementations

Here are some different implementations with descriptions.

Base classes

These classes can be reused for all different implementations.

UnitOfWork

The unit of work represents a transaction when used in data layers. Typically the unit of work will roll back the transaction if SaveChanges() has not been invoked before being disposed.

public interface IUnitOfWork : IDisposable
{
    void SaveChanges();
}

.

Paging

We also need to have page results.

public class PagedResult<TEntity>
{
    IEnumerable<TEntity> _items;
    int _totalCount;
    
    public PagedResult(IEnumerable<TEntity> items, int totalCount)
    {
        _items = items;
        _totalCount = totalCount;
    }
    
    public IEnumerable<TEntity> Items { get { return _items; } }
    public int TotalCount { get { return _totalCount; } }
}

We can with the help of that create methods like:

public class UserRepository
{
    public PagedResult<User> Find(int pageNumber, int pageSize)
    {
    }
}

Sorting

Finally we prefer to do sorting and page items, right?

var constraints = new QueryConstraints<User>()
    .SortBy("FirstName")
    .Page(1, 20);
    
var page = repository.Find("Jon", constraints);

Do note that I used the property name, but I could also have written constraints.SortBy(x => x.FirstName). However, that is a bit hard to write in web applications where we get the sort property as a string.

The class is a bit big, but you can find it at github.

In our repository we can apply the constraints as (if it supports LINQ):

public class UserRepository
{
    public PagedResult<User> Find(string text, QueryConstraints<User> constraints)
    {
        var query = _dbContext.Users.Where(x => x.FirstName.StartsWith(text) || x.LastName.StartsWith(text));
        var count = query.Count();
        
        //easy
        var items = constraints.ApplyTo(query).ToList();
        
        return new PagedResult(items, count);
    }
}

The extension methods are also available at github.

Entity framework

Do note that the repository pattern is only useful if you have POCOs which are mapped using code first. Otherwise you’ll just break the abstraction with the entities instead (= the repository pattern isn’t very useful then). You can follow this article if you want to get a foundation generated for you

I usually start with a small repository definition:

public interface IRepository<TEntity, in TKey> where TEntity : class
{
    TEntity Get(TKey id);
    void Save(TEntity entity);
    void Delete(TEntity entity);
}

which I then specialize per domain model:

public interface ITruckRepository : IRepository<Truck, string>
{
    IEnumerable<Truck> FindAll();
    IEnumerable<Truck> Find(string text);
}

That specialization is important. It keeps the contract simple. Only create methods that you know that you need.

Then I go about and do the implementation:

public class TruckRepository : ITruckRepository
{
    private readonly TruckerDbContext _dbContext;

    public TruckRepository(TruckerDbContext dbContext)
    {
        _dbContext = dbContext;
    }


    public Truck Get(string id)
    {
        return _dbContext.Trucks.FirstOrDefault(x => x.Id == id);
    }

    public void Save(Truck entity)
    {
        _dbContext.Trucks.Attach(entity);
    }

    public void Delete(Truck entity)
    {
        _dbContext.Trucks.Remove(entity);
    }

    public IEnumerable<Truck> FindAll()
    {
        return _dbContext.Trucks.ToList();
    }

    public IEnumerable<Truck> Find(string text)
    {
        return _dbContext.Trucks.Where(x => x.ModelName.StartsWith(text)).ToList();
    }
}

Unit of work

The unit of work implementation is simple for Entity framework:

public class EntityFrameworkUnitOfWork : IUnitOfWork
{
    private readonly DbContext _context;

    public EntityFrameworkUnitOfWork(DbContext context)
    {
        _context = context;
    }

    public void Dispose()
    {
        
    }

    public void SaveChanges()
    {
        _context.SaveChanges();
    }
}

nhibernate

I usually use fluent nhibernate to map my entities. imho it got a much nicer syntax than the built in code mappings. You can use nhibernate mapping generator to get a foundation created for you. But you do most often have to clean up the generated files a bit.

We can use the same base definition as for EF:

public interface IRepository<TEntity, in TKey> where TEntity : class
{
    TEntity Get(TKey id);
    void Save(TEntity entity);
    void Delete(TEntity entity);
}

nhibernate is quite similar to Entity Framework, but it has a Get method which we can use. Hence we create a base class:

public class NHibernateRepository<TEntity, in TKey> where TEntity : class
{
    ISession _session;
    
    public NHibernateRepository(ISession session)
    {
        _session = session;
    }
    
    protected ISession Session { get { return _session; } }
    
    public TEntity Get(string id)
    {
        return _session.Get<TEntity>(id);
    }

    public void Save(TEntity entity)
    {
        _session.SaveOrUpdate(entity);
    }

    public void Delete(TEntity entity)
    {
        _session.Delete(entity);
    }
}

The specialization interface looks the same:

public interface ITruckRepository : IRepository<Truck, string>
{
    IEnumerable<Truck> FindAll();
    IEnumerable<Truck> Find(string text);
}

But the implementation gets smaller:

public class TruckRepository : NHibernateRepository<Truck, string>, ITruckRepository
{
    public TruckRepository(ISession session)
        : base(session)
    {
    }

    public IEnumerable<Truck> FindAll()
    {
        return _session.Query<Truck>().ToList();
    }

    public IEnumerable<Truck> Find(string text)
    {
        return _session.Query<Truck>().Where(x => x.ModelName.StartsWith(text)).ToList();
    }
}

Unit of work

public class NHibernateUnitOfWork : IUnitOfWork
{
    private readonly ISession _session;
    private ITransaction _transaction;

    public NHibernateUnitOfWork(ISession session)
    {
        _session = session;
        _transaction = _session.BeginTransaction();
    }

    public void Dispose()
    {
        if (_transaction != null)
            _transaction.Rollback();
    }

    public void SaveChanges()
    {
        if (_transaction == null)
            throw new InvalidOperationException("UnitOfWork have already been saved.");

        _transaction.Commit();
        _transaction = null;
    }
}

Typical mistakes

Here are some mistakes which can be stumbled upon when using OR/Ms.

Do not expose LINQ methods

Let’s get it straight. There are no complete LINQ to SQL implementations. They all are either missing features or implement things like eager/lazy loading in their own way. That means that they all are leaky abstractions. So if you expose LINQ outside your repository you get a leaky abstraction. You could really stop using the repository pattern then and use the OR/M directly.

public interface IRepository<TEntity>
{
    IQueryable<TEntity> Query();
    
    // [...]
}

Those repositories really do not serve any purpose. They are just lipstick on a pig (yay, my favorite)

The pig is back!

Those who use them probably don’t want to face the truth:

Bush FTW

or are just not reading very good:

Book is upside down..

Learn about lazy loading

Lazy loading can be great. But it’s a curse for all which are not aware of it. If you don’t know what it is, Google.

If you are not careful you could get 101 executed queries instead of 1 if you traverse a list of 100 items.

Invoke ToList() before returning

The query is not executed in the database until you invoke ToList(), FirstOrDefault() etc. So if you want to be able to keep all data related exceptions in the repositories you have to invoke those methods.

Get is not the same as search

There are to types of reads which are made in the database.

The first one is to search after items. i.e. the user want to identify the items that he/she like to work with.

The second one is when the user has identified the item and want to work with it.

Those queries are different. In the first one, the user only want’s to get the most relevant information. In the second one, the user likely want’s to get all information. Hence in the former one you should probably return UserListItem or similar while the other case returns User. That also helps you to avoid the lazy loading problems.

I usually let search methods start with FindXxxx() while those getting the entire item starts with GetXxxx(). Also don’t be afraid of creating specialized POCOs for the searches. Two searches doesn’t necessarily have to return the same kind of entity information.

Summary

Don’t be lazy and try to make too generic repositories. It gives you no upsides compared to using the OR/M directly. If you want to use the repository pattern, make sure that you do it properly.

The post Repository pattern, done right appeared first on jgauffin's coding den.

License

This article, along with any associated source code and files, is licensed under The GNU Lesser General Public License (LGPLv3)

Share

About the Author

jgauffin
Founder Gauffin Interactive AB
Sweden Sweden
Founder of OneTrueError, a .NET service which captures, analyzes and provide possible solutions for exceptions.
 
blog | twitter
Follow on   Twitter   LinkedIn

Comments and Discussions

 
GeneralMy vote of 1 PinmembervbUser200617-Aug-14 12:47 
QuestionRepository pattern, done right (View) Pinmemberrajacsharp59-Jan-14 4:14 
GeneralMy vote of 5 PinmemberHasibul Haque21-Feb-13 19:30 
QuestionSuggestion Pinmembervbdotnetman20-Feb-13 7:46 
AnswerRe: Suggestion Pinmemberjgauffin3-Sep-13 0:59 
GeneralMy vote of 5 Pingroupevan89714-Jan-13 12:17 
GeneralMy vote of 4 Pinmemberrahman_tanzilur0113-Jan-13 11:02 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140902.1 | Last Updated 14 Jan 2013
Article Copyright 2013 by jgauffin
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid