ADO .NET Entity Framework Vote of No Confidence

on

Please refer to the ADO .NET Entity Framework Vote of No Confidence if you care about quality of the Microsoft Entity Framework.

There are a lot of concerns around it. Lots of it came from the community and is not likely to be heard by Microsoft.

So the community puts an open letter to Microsoft which is really very diplomatic and constructive.

Every effort has been made to balance honesty with diplomacy and cooperation.


Since the letter itself is pretty long (which I still strongly recommend to read), I'm putting summary of it here. And if you agree, please vote for it.

PUT ASPECT ON THE MODEL INSTEAD OF DATA THE DATA

EF is data advocates Database driven design, not Model Driven Architecture or Object Oriented. This leads to following the problem that Objects become just Data objects and not really business objects.

 

SUPPORT IMPLICIT LAZY LOADING

Without lazy loading applications will have to include unnecessary prescriptive data loading procedures for every possible business scenario in which the business entities will be used. The business logic of an entity-based app that is not empowered by lazy loading becomes polluted with data access code.

 

SHARED, CANONICAL MODEL CONTRADICTS SOFTWARE PRACTICES

We have found, through years of trial and error, that using separate models for each individual context in which a canonical data model might be used is the least complex approach, is the least costly approach, and the one that leads to greater maintainability and extensibility of the applications and endpoints using contextual models, and it’s an approach that doesn’t encourage the software entropy that canonical models do.

 

PERSISTENCE IGNORANCE

The short story is: Entity Framework classes are too tightly coupled to the persistence. Entity objects should know nothing about where they will be stored where from they will be retrieved.

The tight coupling of the persistence infrastructure to the entity classes largely eliminates the ability to efficiently use very tight feedback cycles on the business logic with automated testing. In its current state, EF entity classes cannot be effectively unit tested independently of the database.

 

EXCESSIVE MERGE CONFLICTS WITH SOURCE CONTROL IN TEAM ENVIRONMENTS

...whenever two developers make changes to an entity diagram... The resulting merge conflicts require merging by hand to avoid corrupting the entity model, as these conflicts are too drastic to be automated by the merge resolution built into modern source control systems

 

Add yourself to the open letter if you do agree with these points.

 

WHAT IS A REALITY - RESPONSE FROM MICROSOFT

Also please make sure you read the response from Microsoft. In a short - they tell the deeply care about all the stuff mentioned which sounds really promising.

And it is really a step forward that EF Team "have a new advisory council to be more proactive in getting thoughts on our work and our directions". This council will include such a great people like:

It looks like Microsoft is changing; in a good way.