locked
What is your comment on this implementation of Unit of work and repository RRS feed

  • Question

  • User-534590683 posted

    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 ....

    https://github.com/TelerikAcademy/ASP.NET-MVC/tree/master/05.%20Working%20With%20Data

    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?

    Regards

    Hadi

    Friday, March 27, 2015 3:03 PM

All replies

  • User-1611549905 posted

    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.

    Sunday, March 29, 2015 5:23 PM