The Repository Pattern is very popular these days. In some environments you will be shredded as a know-nothing if you don't use it for every possible project that involves data storage. And not to knock it, when it was first described, it solved a lot of problems with keeping the code involved with database communication organized and maintainable.

On it's face, it's a great pattern:

"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."

However, when this pattern was created, it was back in the days before Object Relational Managers (ORMs) such as Entity Framework and Hibernate. The more that I've worked with the Repository Pattern in the context of an ORM, the more I find it's getting in the way and causing me to violate the DRY (Don't Repeat Yourself) principle. Every argument that I've heard about using Entity Framework without the repository pattern (Testability, mocking, organization, IoC, handling multiple storage types, etc) has been shot full of holes and solved in the meantime. I really think it's time to think about moving the Repository Pattern to the anti-pattern dustbin of history, just like the good old Singleton pattern has been deprecated.

Back when Martin Fowler's definitive book "Patterns of Enterprise Application Architecture" came out, wayyyy back in 2002, it was a breath of fresh air. Everyone who read it said 'Wow, yes, This guy gets it!' and told all their developer buddies about it, myself included. But even he has this to say about some of his groundbreaking patterns now:

"Another change since I wrote the book is that many patterns are now implemented by common frameworks (particularly with database interaction). This doesn't mean that developers no longer need to understand this material. Frameworks still require you to make decisions about how to use them, and knowing the underlying patterns is essential if you are to make wise choices."

I really appreciate what he said there, and I agree that when it comes to database interaction, some of the patterns don't really apply anymore. But I see a lot of developers sticking to the existing dogma and getting really combative and start spouting insults when challenged out of their comfort zone. But look at how much the software development landscape has changed since 2002. Just about everything, besides the basic language constructs (Which have been massively enhanced since then), has changed - pretty much nothing else is still relevant. Not to insult his book or say the entire thing is irrelevant these days, far from it - there is MUCH to learn from that book, I learned a lot from this book. Just the database stuff is getting long in the tooth. If you haven't read this book, you have to or you are going to be stuck reinventing a lot of wheels. Read it, love it, but still apply only what makes things better, think for yourself, don't get stuck in the dogma - it's not a religious tome.

And to verify my thoughts, I did some checking and found there are many other people with the same thoughts as mine. The best one I found was Do we need the Repository Pattern? which goes over my same thoughts and also includes links to many solutions to the common arguments thrown at people suggesting that the time of the Respository Pattern has come and gone. Another good article is Architecting in the pit of doom: The evils of the repository abstraction layer

Another great thing to see is Ayende Rahien's Breaking Apart Conceptions video on Youtube:

Let me know what you think!