Found Generic Repository Architecture RRS feed

  • Question

  • User-134971871 posted

    I am searching for generic repository which all my data access is in one place for all models. I have found one framework.
    1. https://huyrua.wordpress.com/2010/07/13/entity-framework-4-poco-repository-and-specification-pattern/
    2. https://huyrua.wordpress.com/2012/09/16/entity-framework-poco-repository-and-specification-pattern-upgraded-to-ef-5/

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

    Thank you.

    Saturday, February 14, 2015 12:45 AM

All replies

  • User-134971871 posted

    Any view on this?

    Tuesday, April 28, 2015 2:52 AM
  • User-466603943 posted

    Maybe this will help, it has a Unit of Work Class example halfway down the article


    Friday, May 8, 2015 9:31 AM
  • User-134971871 posted

    Thank you for your reply. I just wan to know that the repository pattern which  found is good or not?



    Wednesday, May 20, 2015 9:00 PM
  • User-1611549905 posted

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

    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.

    Thursday, May 21, 2015 6:27 PM