4 ms·

The many approaches to Entity Framework

31 points by jchannon 14y ago

highace 14y ago
I used to go down the repository/unit of work route but I found that just adds loads of unnecessary abstraction and complication. Now I simply expose the data context through an interface and inject that into my controllers. For testing I use a fake data context.
- jchannon 14y ago
  Unfortunately EF doesn't provide a interface. Unlikely I know but what if you swapped your ORM, wouldn't that mean a lot of refactoring?
  - joshka 14y ago
    IDbSet<T> is enough. If you swap your ORM, you're swapping mindset more than just methods, unless you're mapping ORM entities to POCOs in your repository object.
  - PommeDeTerre 14y ago
    There's going to be a lot of refactoring either way, whether there are custom abstraction layers in place, and whether there aren't. The abstraction layers that were originally intended to ease a transition between ORMs or DBs often end up making such a transition far more difficult. They just end up being another huge amount of code that needs some type of refactoring.
  - dodyg 14y ago
    ORM swapping is YAGNI.
tinco 14y ago
I have the feeling after having done a couple of big C# and Java projects and spending hours refactoring in the same was as this article does that one of the big problems of statically typed languages is the accumulation of abstraction layers. Now this might seem an obvious one, since everyone always complains about the complex types Java projects always seem to have, but it goes deeper than 'Java programmers make weird types'. In my opinion the problem is that interfaces are tightly coupled to types, in the article the author desperately tries to keep IUnitOfWork out of his controllers. He does this by introducing an interface that defines an 'Add' method that itself invokes the 'Add' method on the underlying entity. This seems reasonable but imagine his web application is also a library instead. Someone interfacing with that library would try to keep the authors class abstract from his application layer. Perhaps again defining a class that defines an 'Add' method that hides a call to the 'Add' method the author defined. The problem lies not so much in that interfaces are not a good way of abstracting, but in the reluctance of developers to use interfaces of external libraries, perhaps because it's impossible to decorate classes with interfaces outside of their definition. In dynamically typed languages like Ruby, the interface is nothing more than a convention of which methods certain classes should have, and what parameters they can expect. This makes classes in different layers 'magically' compatible with each other and in this case would immediately skip an abstraction layer or two.
- eksith 14y ago
  You may find the accumulation of abstraction layers is often the biggest problem (with maybe DB inefficiencies being a close second). But that's just a factor of complexity: The more "things" you have in a project, the more layers to accomodate these "things" and therefore the greater the complexity and higher the likelyhood of something breaking. It's not unique to statically typed languages though. Often times when people try to mimic static typing and OOP (badly, a lot of the time) in dynamically typed languages, things are about the same or worse. E.G. PHP
  - throwawayG9 14y ago
    How does PHP "mimic" static typing and OOP?
    - eksith 14y ago
      We recently reworked an app developed in mid 2000's and had the delightful job of working through layer upon layer of abstraction and bad OOP (this was when OOP was becoming en-vogue), but a lot of these apps were written in PHP 4, so they mimicked 5.x with hacks... which then were used to implement abstraction. Yeah, they turned a procedural language into some half-baked-kinda-sorta-looks-like-OOP project in just under 53,000 lines of code. That kind of "mimic".
  - sageikosa 14y ago
    In my humble experience, many abstraction layers in OOP-style projects are the result of the inexperienced developer (acting as an architect) trying to paint himself out of the corner he is most comfortable with, and make everything else look like something he can understand.
    - eksith 14y ago
      I think you're right. I've lost count of how many times I've seen people reimplement PDO from scratch just to mould the whole ensamble to something they find familiar instead of just extending it. Also, like programminggeek says there's a lot of confusion as to where exactly the logic would go in a MVC project leaving developers to pick... wherever to put it. Of course that leads it to change from project to project and even from programmer to programmer in the same project sometimes.

31 points by jchannon 14y ago

I used to go down the repository/unit of work route but I found that just adds loads of unnecessary abstraction and complication. Now I simply expose the data context through an interface and inject that into my controllers. For testing I use a fake data context.

jchannon 14y ago
Unfortunately EF doesn't provide a interface. Unlikely I know but what if you swapped your ORM, wouldn't that mean a lot of refactoring?
- joshka 14y ago
  IDbSet<T> is enough. If you swap your ORM, you're swapping mindset more than just methods, unless you're mapping ORM entities to POCOs in your repository object.
- PommeDeTerre 14y ago
  There's going to be a lot of refactoring either way, whether there are custom abstraction layers in place, and whether there aren't. The abstraction layers that were originally intended to ease a transition between ORMs or DBs often end up making such a transition far more difficult. They just end up being another huge amount of code that needs some type of refactoring.
- dodyg 14y ago
  ORM swapping is YAGNI.

tinco 14y ago

I have the feeling after having done a couple of big C# and Java projects and spending hours refactoring in the same was as this article does that one of the big problems of statically typed languages is the accumulation of abstraction layers. Now this might seem an obvious one, since everyone always complains about the complex types Java projects always seem to have, but it goes deeper than 'Java programmers make weird types'. In my opinion the problem is that interfaces are tightly coupled to types, in the article the author desperately tries to keep IUnitOfWork out of his controllers. He does this by introducing an interface that defines an 'Add' method that itself invokes the 'Add' method on the underlying entity. This seems reasonable but imagine his web application is also a library instead. Someone interfacing with that library would try to keep the authors class abstract from his application layer. Perhaps again defining a class that defines an 'Add' method that hides a call to the 'Add' method the author defined. The problem lies not so much in that interfaces are not a good way of abstracting, but in the reluctance of developers to use interfaces of external libraries, perhaps because it's impossible to decorate classes with interfaces outside of their definition. In dynamically typed languages like Ruby, the interface is nothing more than a convention of which methods certain classes should have, and what parameters they can expect. This makes classes in different layers 'magically' compatible with each other and in this case would immediately skip an abstraction layer or two.

eksith 14y ago
You may find the accumulation of abstraction layers is often the biggest problem (with maybe DB inefficiencies being a close second). But that's just a factor of complexity: The more "things" you have in a project, the more layers to accomodate these "things" and therefore the greater the complexity and higher the likelyhood of something breaking. It's not unique to statically typed languages though. Often times when people try to mimic static typing and OOP (badly, a lot of the time) in dynamically typed languages, things are about the same or worse. E.G. PHP
- throwawayG9 14y ago
  How does PHP "mimic" static typing and OOP?
  - eksith 14y ago
    We recently reworked an app developed in mid 2000's and had the delightful job of working through layer upon layer of abstraction and bad OOP (this was when OOP was becoming en-vogue), but a lot of these apps were written in PHP 4, so they mimicked 5.x with hacks... which then were used to implement abstraction. Yeah, they turned a procedural language into some half-baked-kinda-sorta-looks-like-OOP project in just under 53,000 lines of code. That kind of "mimic".
- sageikosa 14y ago
  In my humble experience, many abstraction layers in OOP-style projects are the result of the inexperienced developer (acting as an architect) trying to paint himself out of the corner he is most comfortable with, and make everything else look like something he can understand.
  - eksith 14y ago
    I think you're right. I've lost count of how many times I've seen people reimplement PDO from scratch just to mould the whole ensamble to something they find familiar instead of just extending it. Also, like programminggeek says there's a lot of confusion as to where exactly the logic would go in a MVC project leaving developers to pick... wherever to put it. Of course that leads it to change from project to project and even from programmer to programmer in the same project sometimes.