C# – Object Composition – Removing Boilerplate Code

I have a single generic repository interface, which is implemented only once for a particular data storage. Here it is:

public interface IRepository<T> where T : class
{
    IQueryable<T> GetAll();
    T Get(object id);
    void Save(T item);
    void Delete(T item);
}

I have implementations of it for EntityFramework, NHibernate, RavenDB storages. Also I have an in-memory implementation for unit testing.

For example, here is a part of the in-memory collection-based repository:

public class InMemoryRepository<T> : IRepository<T> where T : class
{
    protected readonly List<T> _list = new List<T>();

    public virtual IQueryable<T> GetAll()
    {
        return _list.AsReadOnly().AsQueryable();
    }

    public virtual T Get(object id)
    {
        return _list.FirstOrDefault(x => GetId(x).Equals(id));
    }

    public virtual void Save(T item)
    {
        if (_list.Any(x => EqualsById(x, item)))
        {
            Delete(item);
        }

        _list.Add(item);
    }

    public virtual void Delete(T item)
    {
        var itemInRepo = _list.FirstOrDefault(x => EqualsById(x, item));

        if (itemInRepo != null)
        {
            _list.Remove(itemInRepo);
        }
    }
}

Generic repository interface frees me from creating lot’s of similar classes. You have only one generic repository implementation, but also freedom in querying.

IQueryable<T> result from GetAll() method allows me to make any queries I want with the data, and separate them from the storage-specific code. All popular .NET ORMs have their own LINQ providers, and they all should have that magic GetAll() method – so no problems here.

I specify repository implementation in the composition root using IoC container:

ioc.Bind(typeof (IRepository<>)).To(typeof (RavenDbRepository<>));

In the tests I’m using it’s in-memory replacement:

ioc.Bind(typeof (IRepository<>)).To(typeof (InMemoryRepository<>));

If I want to add more business-specific queries for the repository, I will add an extension method (similar to your extension method in the answer):

public static class ShopQueries
{
    public IQueryable<Product> SelectVegetables(this IQueryable<Product> query)
    {
        return query.Where(x => x.Type == "Vegetable");
    }

    public IQueryable<Product> FreshOnly(this IQueryable<Product> query)
    {
        return query.Where(x => x.PackTime >= DateTime.Now.AddDays(-1));
    }
}

So you can use and mix those methods in the business logic layer queries, saving testability and easiness of repository implementations, like:

var freshVegetables = repo.GetAll().SelectVegetables().FreshOnly();

If you don’t want to use a different namespace for those extension methods (like me) – ok, put them in the same namespace where repository implementation resides (like MyProject.Data), or, even better, to some existing business specific namespace (like MyProject.Products or MyProject.Data.Products). No need to remember additional namespaces now.

If you have some specific repository logic for some kind of entities, create a derived repository class overriding the method you want. For example, if products can only be found by ProductNumber instead of Id and don’t support deleting, you can create this class:

public class ProductRepository : RavenDbRepository<Product>
{
    public override Product Get(object id)
    {
        return GetAll().FirstOrDefault(x => x.ProductNumber == id);
    }

    public override Delete(Product item)
    {
        throw new NotSupportedException("Products can't be deleted from db");
    }
}

And make IoC return this specific repository implementation for products:

ioc.Bind(typeof (IRepository<>)).To(typeof (RavenDbRepository<>));
ioc.Bind<IRepository<Product>>().To<ProductRepository>();

That’s how I leave in piece with my repositories 😉