I’m not sure we’ll ever see the end of the ‘Should I use the Repository Pattern over Entity Framework‘ debate online. Another thread about it went up on Reddit recently…
For me in most apps it does not add enough value to justify its usage, in most cases I just don’t think its a good use of my clients money, it’s as simple as that.
‘Swap out’ argument
From what I can see the main arguments for it are that we can ‘swap’ out DB or ORM implementations or guard against MS introducing breaking changes etc. In the small likelihood that these things happen… why not deal with them then?
Our sector rightly so puts a huge amount of emphasis on the importance of automated testing strategies so we can refactor our code with confidence.. but yet we seem so terrified of actually refactoring that a lot of us insist on adding things like repository patterns and paying upfront to cover ‘what if scenarios’ which may never happen. IF you need to change things, embrace that change… let your test suite do its thing.
Better testing support argument
The other argument quite often put forward for using the repository pattern with EF is to aid testability. I get this, but I’m not really a fan of mocking everything out and using too many stand-ins (fakes, stubs, mocks etc.) as I believe there are better ways such as using SQLite or better yet an actual production like clone of sorts.
If my prod system runs on SQL Server 2016 (for example)… I’m going to do everything possible to run my tests against that platform, in which case I don’t need the repository pattern. I believe in most cases the arguments against using an actual prod clone DB to do your testing rather than some other approach relate to speed… in which case I’ll refer you to a quote from the EF documentation…
Multiple different data sources… best use case I’ve seen for repository pattern
For me the uses cases which provide the most justification for the repository pattern relate to when we have or we know for sure we will have multiple different data sources such as SQL Server, Cosmos, DB2 etc. In these cases it can be very beneficial to provide developers in the team with a common abstracted way of working with the various data sources in our service classes.
What is everyone doing? For those wrapping EF in the repository pattern are you returning IQueryable? Are you using a generic repository?
Original post on LinkedIn…
I originally posted a variation of the above on my LinkedIn profile. Check out the original thread for lots of (sometimes heated) discussion about the topic..
