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?
Hello. I think that it’s more reasonable from the DI point of view though. I’m thinking on using Dapper and/or NHibernate in my current project. But haven’t decided if I really need to introduce repositories/uow. What about services? To wrap complex search, query logic?
Thank you.