The many approaches to Entity Framework

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.<p>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'.<p>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.<p>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.<p>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.

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.