Brosteins

Developers, Technology Evangelists, Bros.

Why Not to Use the Repository Pattern

The Repository pattern, as described by Edward Hieatt and Rob Mee in Martin Fowler’s Patterns of Enterprise Application Architecture, is a layer of abstraction that is used to mediate interactions between the domain and the data mapping (ORM) layers. You can use a repository to minimize the duplicate query logic that a can arise in larger domains.

Often times, I see a Repository<T> built on top of an ORM like NHibernate or Entity Framework, offering methods like of FindById(), Find() to return one or a collection of domain entities. With NHibernate and Entity Framework both offering similar functionality, I don’t feel adding this layer of abstraction will give you a sufficient advantage over using the ORM directly.

Another justification for a Repository I’ve heard is “to easily change ORM implementations, if needed in the future.” Although PoEAA cites this is one of many reasons to use a Repository, I don’t feel this alone should be a reason to use a Repository. How often do you actively change ORM implementations? Better yet, have you ever changed an ORM implementation during a project? In my experience, changing ORMs doesn’t happen too often, and when it does, I have felt that having a Repository hasn’t saved me a significant amount of time.

I prefer to approach system design with simplicity, clarity of meaning/purpose, and reduction of wasted effort. Repository implementations I have seen only served the purpose.of adding another layer of unnecessary complexity, while wasting the time to implement a layer that “you aren’t going to need.”

What do you think?

Share

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.