Last post Jul 15, 2014 04:05 AM by Mikesdotnetting
Jul 14, 2014 09:40 PM|dotnetterAMG123|LINK
Jul 15, 2014 02:09 AM|Mikesdotnetting|LINK
Pretend you're a principal consultant at a consulting firm
Not a good idea if you want a straightforward answer ;-)
The current recommendation for data access in .NET applications is the Entity Framework. If you want to abstract your DbContext behind a unit of work facade, you can do so, and you can wrap your DbSets behind a repository facade too: http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application.
However, since the DbContext is an implementation of unit of work and the DbSet class is an implementation of the repository pattern,you might not bother: http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/advanced-entity-framework-scenarios-for-an-mvc-web-application#repo
Jul 15, 2014 03:29 AM|jammycakes|LINK
It's difficult to give a "one size fits all" answer because every project is different. However, I can point to a few things that have changed in the past five years:
The first thing I'd say is that if there's one lesson we've learned over the past five years or so it is that making your data access layer pluggable doesn't work. It used to be (and still is by some) considered a "best practice" to architect your code so
that you can, say, swap out NHibernate for Entity Framework or RavenDB at a later date if you need to. The problem with this is that you end up building something that locks you out of important features of your ORM, such as lazy loading, caching, prefetch
queries, transactions, and so on. Performance is usually the first casualty: every project I've worked on that tried to do this has been riddled with select n+1 problems that brought it to its knees at times. Either that or else you'll end up attempting to
reinvent Entity Framework on top of NHibernate (read: masses of effort, buggy, unreliable, you'll almost certainly get it wrong anyway, not worth it.) Unless your client specifically demands it, and is willing to pay for the extra effort involved, don't go
Secondly, a traditional SQL database is not your only option. There's been an increasing interest in alternatives in recent years, with NoSQL databases such as RavenDB and MongoDB becoming increasingly popular. Graph databases and triple stores are also
worth considering for graph-based business rules such as relationships in a social network, train fares and routes between arbitrary stations, or versions and changesets in a source control system.
Thirdly, there's an increasing interest in architectures other than the traditional UI/BLL/BOL/DAL layered architecture. CQRS/Event Sourcing in particular is getting a lot of buzz at the moment, though you need to make sure you know exactly what problems
it solves and that you actually have those problems, because it can just complicate your code unnecessarily if used inappropriately.
Jul 15, 2014 04:05 AM|Mikesdotnetting|LINK
though you need to make sure you know exactly what problems it solves and that you actually have those problems, because it can just complicate your code unnecessarily if used inappropriately.
I think this is a good point and can be applied to the whole application architecture. Take an interest in other people's patterns, but bear in mind the two most important principals: