The Entity Framework 5 and even previous versions of the product is indeed an amazing product.   And it is a good thing that the Entity Framework is trying to solve a lot of problems that previous tools have such as Hibernate, nTiers, or others.  The idea here  is that it is supposed to make it simple to think of objects and their relationships on the data layer and merge those changes onto the View layer through some ridiculous controller intermediary action.

But seriously this is extraordinarily flawed logic.  This is basically taking an idea that grandpa had however smart and trying to re-configure it for the 21 and 22 centuries.

Flawed. Flawed. Flawed.

Here is what should happen using a phrase I just love,  "Short circuit the problem."

But how would you short circuit the problem if you got Sql Server 2008 R2, SQL Server 2012, Oracle's database versions, IBM's database versions, and even other extraneous versions.  And you also have all of these NoSql - Couch Dbs which do sort of short circuit the problem but not really.

The main jist here that the connection from your code to the data server is the main problem.  The IIS server or your web server is completely separated and major conversions need to take place especially where advanced complex relationships are taking place in order to transition the logic to the web server through the model, then, a controller and then to crud in a view.  Wow... talk about a headache.

To simplify this I've noticed that sql could be the controller action by default.   So how could you give some code the responsibility of the controller?   You don't re-create the sql server box.  What you do is you give the the sql server the responsibility to define entities and add a field that has an entity framework types or just assume that the big binary object is that type.   You could just send those types from .net to Sql 2012 as a byte[] to a blob field  in a tracking table and then track that blob through a relationship.  Then add fields on what the operation is such as a index, detail, create, update, delete, insert.  Then you could also add another field to tell the EF5.1 + version what the output should look like such as json, restful, some new Klingon syntax, or whatever.  Why put that on the EF5's back man???  Seriously flawed.

Finally to solve everything...  The EF5 would submit this blob crud to the database automagically and maybe use like some guid or whatever to uniquely identify the topology.  Simple.     I think the problem this would solve is dynamic flux changes.  Utilizing view, sprocs, udfs, and tables in dynamic CRUD operations.   This would virtually solve the data first design methodology and there wouldn't be a sql command that would be lost in translation unless you started using varbinary or blob fields which is only what the EF should use for tracking.

Anyway,  There is probably only one person at Microsoft that can even decipher this blog so to everyone else just keep doing whatever is you are doing because things are about to change for the better.  I hope.