Tim's Blog

I'm far from an expert on Microsoft's Entity Framework (EF), but I have dabbled a bit with betas 2 and 3. Recently, Brian Ellis, a colleague of mine, summarized the points made in an open letter claiming a "vote of no confidence" in the Entity Framework. I'm no ORM guru or EF junkie, but I know enough about EF to see that it has both potential and limitations. I'd like to share my thoughts on the letter.

To be fair, I've never used NHibernate (the Holy Grail), and work primarily with Microsoft technology. That doesn't make me an EF evangelist. I'm still quite skeptical, but interested in understanding the value of the technology.

Before getting into the issues mentioned in the open letter, I would like to add a few gripes of my own:

• The design surface is not feasible for maintaining hundreds of entities.
• The mapping seems to be brittle when using the designer for custom entities, including the refresh from schema feature.
• The designer forces the developer to refresh from schema in certain cases, when perhaps she doesn't want to.
• Generated code in an entity data model does not represent self-referencing schema very well (for instance, an Employee that inherits from Person, which has a Manager property that also inherits from Person). Customizations required to work around the issue are hard to maintain.

I'm sure the more I use it, the more gripes I'll have, but for now let's get to the gripes of the open letter.

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

Regarding the point that entities are tied too closely to schema, I believe this is often true, but only because unmodified, generated code is the simplest and most common way to build an entity model—straight from schema. They don't have to be, however. From my understanding, a decent amount of flexibility is provided for structuring entities and their relationships, included multiple inheritance patterns, and the ability to group mapped columns into complex object properties.

(For instance, a Person table may contain several columns related to addresses. You could create a complex type called Address that a Person entity uses, and map the properties of the Address property to the columns in the Person table. No Address table is required in the data store, just proper mapping.) I'm sure, however, that many entity models would be very difficult, or impossible, to map using EF.

Regarding the point that entities are data-centric, rather than behavior-centric, I might not fully understand the complaint. The authors make no mention of the fact that the entities are partial classes with full exposure to the EF's data access gateway, allowing custom business and data access logic to be attached to each entity. (They do mention the partial class architecture in the "persistence ignorant" section, but only to complain of its "awkwardness.") It seems to me that custom entities could be designed with behavior in mind.

EXCESS CODE NEEDED TO DEAL WITH LACK OF LAZY LOADING

EF supports deferred loading, but requires the developer to understand when any related entities ("navigation properties") are loaded, rather than automatically fetching & load-tracking when referenced. It's true, this causes the developer to ask IsLoaded() of an entity's navigation properties, and then conditionally Load(). You can also eagerly fetch navigation properties when fetching the parent by using the .Include() method, but this is pretty much the opposite of lazy loading. It sounds like the authors of the letter do not want developers to need to understand when or if a property has already been loaded. I don't really have an opinion on this since this requirement hasn't given me enough heartburn to gripe about it.

SHARED, CANONICAL MODEL CONTRADICTS SOFTWARE BEST PRACTICES

If I understand correctly, the authors of the letter are proponents of separate models per application tied to a single data store, rather than a single, canonical, model shared by multiple applications. This seems fully feasible with EF—there's no reason multiple models could not represent and access the same data store. Am I missing something?

Even better in certain cases, it seems possible with EF to place all core, sharable logic in a shared entity model, and have application-specific logic in each application that consumes the model. This architecture would probably break the partial class pattern of putting the logic directly in the entity, but if the logic is application-specific, I don't think it belongs there anyway. This could be handled with a more classically-tiered approach using service layers or business layers in consuming applications.

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

I think this is a little misleading, because the entities themselves are persistence-ignorant, but obviously the mapping configuration cannot be. Perhaps I'm missing something, but that seems to be the nature of ORM. In order to connect an entity data model to two completely different data stores (in schema, technology, etc.), you would have to take great care in creating two separate mapping configurations to ensure they provide equivalent mapping. Even then, you are limited by the differences in what the two data stores support. For instance, you can't expect an XML file to support cascading deletes or other features that SQL Server provides. However, if we ignore the differences in the features of data store technologies and focus solely on mapping, I believe the EF supports persistence-ignorant consumption of entities, allowing for unit testing, data migration, etc.

EXCESSIVE MERGE CONFLICTS WITH SOURCE CONTROL IN TEAM ENVIRONMENTS

This wouldn't surprise me, but I have no experience with EF in source control.

In summary, I feel like the open letter attempts to make some good points, but doesn't do much to back them up. It also seems that certain features of EF are glossed over, or perhaps EF is just not enough like NHibernate for those that wish it was. I'm not an EF evangelist, and I'm sure when it's finally released it will stir up a lot of complaints (by me, included), but this letter smells a bit like alt.net vs. MSFT to me.