Is Repository old skool?

I used to be a fan of Repository pattern, DAO, DAL whatever they're called. I have tried many different approaches for this pattern and normally end up at a DAO object rather than a pure generic Repository. However, I still fooled myself that it was my bad design of Repository pattern and there must be a better design somewhere. More than two years ago, I saw code of my elder colleague about his design of database abstraction layer. He used Specificication pattern together with the Generic Repository on top of Entity Framework. I talked to myself, what the hell is specification and why on earth would we want to use it when we have LinQ built in in the language. Hmm, I might be wrong at time time and now I know I was properly wrong. Recently, I'm watching a interesting argument among many blog readers on a topic of Oren's blog. Basically, they're arguing about whether we should use Repository Pattern. I'm confused about the trend of community on this topic so I decided to ask my 2 experienced colleagues. Here are their responses:


I don’t tend to use them these days ...

A Repository in concept is “an in-memory list” for all intents and purposes ... the problem is they are almost always written as “a generic data access layer”. The main problem is that Repositories should only *ever* be for an Aggregate Root, and therefore handle all data access for all child objects too. Ours are a nasty generic data access layer pretending to be a repository.

Personally I usually favour QueryObjects for querying and CommandObjects for writing

In this case a QueryObject knows how to do one query or projection (which may involve database calls), and returns either DTOs or domain entities

A CommandObject knows how to do one single operation, which may involve multiple database calls), and returns Void



Or as I think Oren advocates later on, I would just let the NH objects into the domain these days – nobody ever replaced a data layer
Jak Charlton


I usually, but not always, tend to judge the repository pattern as an anti-pattern and an unnecessary additional layer of abstraction, complexity and maintenance. It's quite useful if you're going to need to swap out your storage platform at some point, say SQL Server for Oracle or MongoDB, but even then there are often underlying specific implementation differences between platforms that break the abstraction compatibility, so you end up needing to redesign the repository's API contract and break compatibility. A generic repository that works across several storage platforms must be very generalised, and isn't able to leverage specific features of a particular technology.

This only applies to a generic repository, I see less harm in it when applied more specifically, like EF which provides a good storage abstraction and API over relational databases.

As always, it depends. I currently tend to design for a service layer that directly uses a mirco-ORM for SQL Server, and other data access libraries specific to their storage type, like the .NET MongoDB driver.
Chris Fulstow


Well, clear enough. These comments plus people's comments on Oren's post tell me that I'm at least 3 years out of date. Repositories are nolonger hot fashion even though I believe there are still more guys like the old me still see the value of Repositories. I had seen enough problems using Repositories as a generic Repository can easily become a DAO at some point otherwise it would lose many features of the ORM technology abstracted behind it. Properly QueryObjects are the one to go for me next time :D.