
The many approaches to Entity Framework - jchannon
http://blog.jonathanchannon.com/2013/03/04/the-many-approaches-to-entity-framework/
======
tinco
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
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

~~~
sageikosa
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
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.

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

~~~
PommeDeTerre
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.

