Repositories! Repo what??

Lately, the Repository pattern has become the conversion topic almost every day, mostly because nowadays it’s a so popular pattern, and most people get admired on the fact that I prefer to avoid it, in favor to expose the ORM to the service layer. So I thought about publicly exposing my why, so I can remit here and not repeat myself every time.

For introduction to the Repository, check here. This post will also be an extension from what I’ve already said on my previous post.

Let’s get to the point. My first problem with Repositories is that they hide, and often blocks you the use of advanced features of the actual ORM. Future queries, cascade deletes, batch updates, etc…

I’ve seen two different strategies with repositories. The most radical one, it’s a full closed box, where they implement every query that needs to be issued. They main advantage of this method is that there’s a single place where all queries sit, at the cost of filling each repository with methods for each different type.

public interface ICarRepository : IRepository
{
    Car GetById(int id);
    Car GetBySerialNumber(string serialNumber);
    IEnumerable<Car> GetRedCars();
    IEnumerable<Car> GetRedCarsInPortugal();
    IEnumerable<Car> GetClientOrderCars(int clientId);
    /* And other....  */
}

The other way, is build one generic, fits all repository. This is also the most common example you can find on the internet. I usually find in this way some flaws:

So…. Let’s analyse this the other way around. What’s the reasons I ear this pattern being defended…

Ok, so what do you use then? Queries and Commands! But I’ll explain that a little bit better on my next post.


comments powered by Disqus