I'm about to use ADO.Net Entity Framework for the first time in a real project, so it's probably a worthwhile effort to look into with what happened last year: vote of no confidence towards the entity framework. The wordings in the letter is highly sophisticated....to the extent that I'm scratching my head wondering what some of that mean. So here is my finding, in a [more] logical order.

Not long after that, Microsoft introduce an advisory council for the next release of ado.net, presumably entity framework 2. The council include names like Eric Evans (famous for DDD) and Martin Fowler (famous for design and architectural patterns)

INORDINATE FOCUS THE DATA ASPECT OF ENTITIES LEADS TO DEGRADED ENTITY ARCHITECTURES

EF only focusing on data and there's no way of attaching behavior to it, which leads to Anemic Domain Model anti-pattern. So if you're using EF as an OR/M, it only cover half of the story.

EXCESS CODE NEEDED TO DEAL WITH LACK OF LAZY LOADING

need to be done explicitly instead of working out what needs to be loaded in a call.

var result = entityFrameworkContext.Book.First().Chapters; //return 0 items 

var result = entityFrameworkContext.Book.Include("Chapters").First().Chapters; //return 4 items 

//or

var book = entityFrameworkContext.Book.First();
book.Chapters.Load();
var chapters = book.Chapters; // return 4 items

as a result, we start caring about how the persister layer interact with the database at a domain layer. EF team's justification for this was in a large enterprise application you want total control over the loading of the data.

LACK OF PERSISTENCE IGNORANCE CAUSES BUSINESS LOGIC TO BE HARDER TO READ, WRITE, AND MODIFY, CAUSING DEVELOPMENT AND MAINTENANCE COSTS TO INCREASE AT AN EXAGGERATED RATE:

kinda continues the idea from the 2 points mentioned previously. Database are tightly coupled to models within the EF context and data access techniques are leaked on to the domain level.

SHARED, CANONICAL MODEL CONTRADICTS SOFTWARE BEST PRACTICES

I think here the letter talks about more than just Entity Framework but also covers ADO.Net Data Services (Astoria).

Canonical model contain the big picture, but does it still maintain efficiency?

The idea is to provide a single location to 'store' all your different enterprise applications' entity data models. This scenario is comparable to the fact that we often have one massive enterprise database guarded by numerous db admins.

I actually like the idea from a DRY point of view. It is many companies dream to have a central storage of data and business rules.On the other hand, from a Domain Driven Design point of view, it's nearly impossible to have one model that works well for any type of applications.

However, there's nothing that stopping from anyone to build software using EF in silos.

EXCESSIVE MERGE CONFLICTS WITH SOURCE CONTROL IN TEAM ENVIRONMENTS

Pretty self explanatory. This just simply means expect to see alot of Auto Merge failed message, and having forced to do a manual merge with beyond compare when working in a team.