The many approaches to Entity Framework
blog.jonathanchannon.com
blog.jonathanchannon.com
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.
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
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".
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.
Better patters would help avoid all the layers.
In the case provided, the whole thing was just an architectural mess.
There should be one abstraction which is the transaction and unit of work boundary in the form of a service layer so the application looks like:
controller <--> service <-> model/repository
The transaction and unit of work boundary above is inside the service. This should be entirely controlled by framework/container or chucked in there manually (see example below).
The model/repository should pretty much be whatever the native ORM interface is. it ain't worth abstracting it for shit as you're not going to change it, ever. In the case of NHibernate, which I'd recommend over anything else, your code would look like:
class UserService {
// ... DI crud here.
public BooleanResult AddUser(UserTransferObject userTransferObject) {
// Validate shit here
// Create shit
using (var session = sessionFactory.OpenSession()) // UOW boundary
using (var trans = session.BeginTransaction()) // Transaction boundary
{
var user = User.CreateFromTransferObject(userTransferObject);
session.Add(user);
trans.Commit();
return BooleanResult.Success();
}
}
}
You can add a repository abstraction in there as well if you really fancy it but I wouldn't bother.
I agree about your approach regarding a service in a larger app but in a smaller app I have come to the conclusion today that IDBContext injected into a controller would be better than a repo, as you say you arent going to change ORMs in reality and it exposes the native functionality of your ORM.
I agree with your your example though, as well as your point about the model/repository being whatever the native ORM interface is. If you're using EF and you REALLY thought you might swap it out later for something else you could always use its POCO mode so you would at least have your business objects intact and reusable.
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.