Graphinder – Queries and Commands vs Repository pattern


While planning a data access layer for Graphinder project I found myself really frustrated with Repository pattern, that I’ve followed for quite a time like a mantra, that was spread by many business and by Microsoft itself. But since Entity Framework 6 already provides a mix of repository and unit of work pattern, why would I build yet another abstraction over it?
That’s when I stumbled upon a concept of Queries and Commands, known especially from CQRS (Command and Query Responsibility Segregation). I would like to emphasize here, that I’m not 100% into CQRS. I like to think of myself as a picker of what’s best for me from any either newer or older pattern/approach. I’m nobodies blind follower.

What’s wrong with Repository pattern

Repository is a good-old pattern that is around here for some time already. Its purpose is quite simple:

The repository mediates between the data source layer and the business layers of the application. It queries the data source for the data, maps the data from the data source to a business entity, and persists changes in the business entity to the data source. A repository separates the business logic from the interactions with the underlying data source or Web service.

So we have mediating, we have mapping (post about persistence models: Domain models vs Persistence models) and we have seperation. And we do agree with those points, right? Right.
But things are not so simple out there. Repositories often end up as big, bloated almost-god-objects with lots of one-time-usage methods, spanning to mostly hundreds and hundreds of line. When we see such class in domain/business layer, what do we think first? Decomposition!

Why such thought have not been born here? Why encourage things like this (example exaggerated on purpose):

Of course we can go with query that takes one object of query params that will have milion of properties inside of it. And we can keep on going on this. But why?

Queries and Commands – decomposition

Why not go the other way round? When I see such big object with big responsibilities, I think decomposition.
I don’t care if it is most adore pattern in the world. From the moment I look at it, I can see how a great idea is so wrong much too often on implementation side. Why wouldn’t I go for something like this instead:

Can’t a simple insert operation be like this instead:

I know what would you ask now: how do I test then?
Question is, what would you like exactly to test here, except of maybe null or empty string or invalid debt value (which you can still test here)? Or maybe its ORM you want to test here? But let’s assume you really want to. What now?
You could simple create abstraction, ie. IUserContext instead of DbContext and expose it either through ctor or through public property. You can mock it now, you can stub it now.

So, how about replaceability here?
It has been said that it’s a common myth that databases are commonly swapped in business applications.
I would say that yes: it is quite rare. But it doesn’t stop you from being prepared!
In a rise of NoSQL solutions, it will also be much more easier to play around and test new technologies.
But hey, we already got it hidden from both domain and services layer, don’t we? Caller doesn’t care what is called up there. And that’s our goal.
As for replacing… Well, provided we don’t want to go through each query and command class to make an actual swap, we might want to expose Context up and just inject a property through any mainstream IoC container.
As an example, Autofac offers it out of the box: http://docs.autofac.org/en/latest/register/prop-method-injection.html#property-injection


Let’s sum it up then:
I guess I’ve just unsubscribed myself from Repository fan club.

Leave a Reply

Your email address will not be published. Required fields are marked *