Last post May 21, 2015 06:27 PM by jammycakes
Feb 14, 2015 12:45 AM|mayurlohite|LINK
I am searching for generic repository which all my data access is in one place for all models. I have found one framework.
Here is download link :
I have downloaded [net45] converted it to EF6 working fine I just want to understand or know that its a good architecture for my new MVC project.
My new project is not very big but not very small its middle complex application. So huyrua architecture is good for me????
Sopmething to code | Nullplex
Apr 28, 2015 02:52 AM|mayurlohite|LINK
Any view on this?
May 08, 2015 09:31 AM|rlowe7117|LINK
Maybe this will help, it has a Unit of Work Class example halfway down the article
May 20, 2015 09:00 PM|mayurlohite|LINK
Thank you for your reply. I just wan to know that the repository pattern which found is good or not?
May 21, 2015 06:27 PM|jammycakes|LINK
The repository pattern is largely misunderstood.
The primary purpose of the Repository pattern is to provide a collection-like interface to your entities--so you can enumerate them, fetch them by ID, add them, update them, delete them and so on. As such, Entity Framework's DbSet<T> class is itself a Repository.
What you see in far too many codebases are classes called "Repository" that are nothing more than an anaemic abstraction layer around your O/R mapper. This is actually a misunderstanding of how it was originally described in
Patterns of Enterprise Application Architecture. (See
my blog post on the subject for more details.)
The usual justification for such an abstraction layer is that you should be able to swap out Entity Framework for something else--either test mocks or an alternative implementation.
In the case of test mocks, you don't need an abstraction layer for that with EF6 or later: in most cases you can mock DbContext and DbSet directly, and in the cases where you can't (for example, when you're calling .Include() to specify prefetch paths),
you need to hit the database, since mocks won't provide you with an accurate reflection of what happens in reality. So while it may have gained you something with older versions of Entity Framework, or with other ORMs, you gain nothing from it nowadays in
In the case of alternative implementations, you're wasting your time and your client's money. Swapping out Entity Framework for NHibernate, or Linq to SQL, or Dapper, or RavenDB, or a web service, is far, far, far more complex than just sliding in an alternative
IRepository implementation. You would have to abstract out behaviour as well as method signatures, and that's where things get very, very messy very, very quickly. (Examples: when and how are primary keys allocated? How are enums persisted to the database?
How are many-to-many relations handled? What error is thrown when you have a foreign key violation? What happens when you ask for an entity that doesn't exist--does it return null or throw an exception? How do you specify prefetch paths?) In general, unless
you know up front that you will need to support different data sources and unless you can develop for them both simultaneously from the outset, you're going to run into a lot of trouble.
Personally I recommend that you don't wrap your O/R mapper in a separate IRepository wrapper. Just inject your DbContext directly into your business layer.