none
Good or Bad: Repository pattern with Entity framework?? RRS feed

  • Question

  • Suggestions about not to use enttity framework because:
    1) entity framework is itself a Repository pattern
    2) So, what the use of having one more repository pattern over an exisitng repositroy pattern (i.e Entity framework)

    Please suggest.

    Thanks in advance!!
    Thursday, July 24, 2014 10:20 AM

Answers

  • I am not a fan of the Repository pattern period. I saw it in action a few years ago with a solution that was using nHibernate. I just didn't care for it, and it was just too complicated. I didn't see the bang in it.

    When I am architecting n-tier solutions, I have always stuck with a DAL classlib project pattern. One class/object per table to do CRUD operations. The class/object used an interface, which made it unit and functional testable using a test harness like MSTest Unit Test or Resharper.   

     
    Friday, July 25, 2014 3:58 AM

All replies

  • I am not a fan of the Repository pattern period. I saw it in action a few years ago with a solution that was using nHibernate. I just didn't care for it, and it was just too complicated. I didn't see the bang in it.

    When I am architecting n-tier solutions, I have always stuck with a DAL classlib project pattern. One class/object per table to do CRUD operations. The class/object used an interface, which made it unit and functional testable using a test harness like MSTest Unit Test or Resharper.   

     
    Friday, July 25, 2014 3:58 AM
  • It depends on your architectural goals.

    The repository pattern is data access for a domain model. An entire object graph. It should be used when using Domain Driven Design.

    I've used both nHibernate and the Entity Framework 6 and nHibernate wins hands down as the best orm, despite it's learning curve. ORMs can be massive timesavers as you don't end up writing boiler plate db access code.

    Unlike the previous responder I disagree with testability, each repository should have it's own interface. And if implemented correctly it can save tones of time as you need only mock one or two repository methods rather than 10s or 100s of database gateway call using one class per table.

    In my opinion domain models result in far cleaner code as it allows itself to proper object orientation and mapping to a problem domain.

    As such, in summary, a repository is designed to map a object/domain model to a relational model for storage in the database. If you've not got a rich domain model, then don't use the repository pattern. 



    • Edited by Andy CC Wednesday, December 31, 2014 2:02 PM
    Wednesday, December 31, 2014 2:00 PM
  • I've used both nHibernate and the Entity Framework 6 and nHibernate wins hands down as the best orm, despite it's learning curve. ORMs can be massive timesavers as you don't end up writing boiler plate db access code.

    I used 3 different versions on nHibernate over the years. I didn't paticulalry care for any version of nHibernate. I much prefer EF over nHibernate any day of the week, month or year.

    Unlike the previous responder I disagree with testability, each repository should have it's own interface. And if implemented correctly it can save tones of time as you need only mock one or two repository methods rather than 10s or 100s of database gateway call using one class per table.

    What? Like a  DAO can't  have an interface, which is just as testable as any repository pattern using an interface when using a test harnerss and testproject to test the DAO? And one has to go beyond some generic repository pattern in unit, functional and intergation testing when it comes to data access. 

    Unlike you, I want complete control of the object all aspects of it even in its usage of other DAO(s) that could or would be used, which the  repository pattern doesn't cut it for me. 

    Like I said, I'll take EF over nHibernate, which is much like talking MS SQL Server over Oracle with Oracle being a PITA to work with it.

    Wednesday, December 31, 2014 4:05 PM