Last post Mar 29, 2015 05:23 PM by jammycakes
Mar 27, 2015 03:03 PM|hdi.amiri|LINK
I wanted to know do you guys recommend this method for accessing data in asp.net mvc?
pros and cons of this method?
what is the best way to organize solution and data base context and doing separation of concern and ....
Edit: I know that since EF 6 onward, they have both implemented UoW and Repository, but my question is that: when I take a look at source code of "nopcommerce", "smart store" or this https://github.com/NikolayIT/BlogSystem or
this https://github.com/NikolayIT/OpenJudgeSystem , they have different methods of data access! but why ? I mean those guys aren't smart enough to see that they are doing redundant work?
Mar 29, 2015 05:23 PM|jammycakes|LINK
You're right in saying that Entity Framework implements the Repository and Unit of Work patterns itself, and in fact the functionality in the "Repository" classes in these projects would actually be better served by extension methods on DbContext or IDbSet<T>.
In most cases, when people build "Repository" or "Unit of Work" classes, what they are building isn't actually a Repository or a Unit of Work per se, but an abstraction layer. This can have some benefit for unit testing if you are using O/R mapper functionality
that is difficult to mock (e.g. Linq to NHibernate, which relies heavily on extension methods), but EF6 can actually be mocked to an extent (see
this post by Julie Lerman for some details on how to go about it) so that point is generally moot.
You also sometimes hear people trying to justify it by saying you "might need to swap out Entity Framework for a different data source." This practice generally dates back to the days before Entity Framework when the only O/R mapper in town worth using was
NHibernate, but since far too many .NET teams don't like using non-Microsoft solutions, they tended to treat it like a crazy aunt locked up in the attic and tried to architect their solutions so they could in theory swap it out for the Microsoft-anointed offering
as soon as it was mature enough to be usable. I say "in theory" here because in practice, swapping your data source is vastly more complicated than just wrapping IRepository and IUnitOfWork interfaces around it -- you have to take into account differences
in behaviour as well, and these can get very, very messy very, very quickly.
Apart from that, it's mainly a case of "old habits die hard." Another factor is that the Internet is groaning at the seams with tutorials and examples presenting this as The Way That You Are Supposed To Do Things, while most of the examples presenting an
alternative tend to implement unnecessarily complex flavours of DDD/CQRS/Event Sourcing/Messaging/NServiceBus/Jean-Luc Picard, and as a result there aren't that many sample applications out there that cut out all the complexity that simply isn't necessary
for 95% of the kind of applications that people build in Real Life.