locked
Why Repository Pattern over Entity framework? RRS feed

  • Question

  • User485493498 posted

    Hi,

          As we use entity framework in DAL which have a built in feature of Repository pattern. But I have seen many practices that some developer still write separate repository pattern over entity framework, why we do that even though we already have with EF?

    Regards,

    Imran Ahmad Mughal

    Monday, October 20, 2014 7:37 AM

All replies

  • User-1611549905 posted

    It's because there's a widespread misunderstanding of the description of the Repository pattern in Patterns of Enterprise Application Architecture.

    The Repository pattern talks about an abstraction around the "data mapping layer." Most people these days just assume that that means your ORM in its entirety, but it doesn't. It means the specific part of your ORM that copies data between generated SQL queries and your objects. Patterns of Enterprise Application Architecture was written in 2003, at a time when O/R mappers in .NET were mostly expensive, commercial offerings that were very basic compared to today's offerings. Hand-crafted SQL and stored procedures were pretty much the norm.

    In theory, the Repository Facade pattern (I use this term to distinguish it from the Repository that you get in your ORM) is supposed to decouple your business layer from your data access layer so that you can swap out Entity Framework for something else if need be. In practice, it doesn't. Swapping out your persistence mechanism is vastly more complicated than that: the Repository Facade only encapsulates about 10% of your ORM's functionality and doesn't address the numerous subtle behavioural differences between different data access mechanisms. Besides, it's usually a non-functional requirement that the business isn't asking for.

    The main benefit that it offers you is a central place to put your queries. However, more often than not, this results in an anaemic business layer that doesn't do anything other than shunt data unchanged from your DAL to your presentation layer, just cluttering up your code with unnecessary levels of indirection.

    I generally recommend avoiding the Repository Facade until you encounter a genuine reason why you need it, for example, to bypass Entity Framework and drop down to raw SQL for performance reasons. For most queries, I prefer a different approach using query objects, which are much more lightweight and maintainable.

    Monday, October 20, 2014 8:48 AM
  • User-760709272 posted

    Hi,

          As we use entity framework in DAL which have a built in feature of Repository pattern. But I have seen many practices that some developer still write separate repository pattern over entity framework, why we do that even though we already have with EF?

    Regards,

    Imran Ahmad Mughal

    You can normally treat Entity Framework as the repository rather than using it via a repo you create yourself.  If you look at the repository methods in those implementations they are usually one-line methods that do nothing but pass the query onto an EF context object.  So it is normally ok to just not bother with your own repository pattern, you don't get a lot out of it.

    Monday, October 20, 2014 8:59 AM
  • User485493498 posted

    Hi Jammy,

                    Could you please provide me tutorials/url from which I can get better understanding regarding design patterns?

    Regards,

    Imran Ahmad Mughal

    Tuesday, October 21, 2014 12:38 AM
  • User-1611549905 posted

    I presume you already have some experience with design patterns since your original question was a fairly intelligent and well informed one. That being the case, I'd recommend you take a look at the series of posts "Design patterns in the test of time" by Oren Eini (Ayende Rahien). It's also worth reading the classic post "Why I hate frameworks."

    For tutorials at whatever level, my best recommendation here is for the video-based tutorials at Pluralsight. Unfortunately it's a subscription service, but the old adage "you get what you pay for" applies here: you're paying for quality control and the assurance that you're learning from experts with an established reputation in the field. There are a lot of freebie tutorials out there, but their quality is variable at best and often dangerously low, with many samples being riddled with race conditions, security vulnerabilities, or worse.

    As a bonus though, most of the authors of Pluralsight courses have their own blogs and Twitter feeds and you can learn a lot from those for free too.

    Tuesday, October 21, 2014 2:46 AM