Entity Framework Team Abandons Unified N-Tier Architecture for v2

Updated 11/21/2008: See below

Jeff Derstadt, Jaroslaw Kowalski, and Diego Vega posted on 11/19/2008 a lengthy N-Tier Improvements for Entity Framework [v2] article, which proposes the following “goal” for change management in future n-tier implementations:

Entity Framework won’t define its own unique representation for the set of changes represented in an N-Tier application. Instead, it will provide basic building block APIs that will facilitate the use of a wide range of representations.

The decision to abandon a unified n-tier architecture for EF v2 appears to stem from the anticipation that users would expect such a design to offer the programming simplicity of DataSets (represented by Martin Fowler’s Table Module pattern) combined with the versatility and strong decoupling offered by Data Transfer Objects. The availability of ADO.NET Data Services to provide a REST-based tiered service layer probably contributed to the designers’ justification of an n-tier non-goal.

To achieve the proposed non-goal, the team intends to supply helper methods that developers can mix and match for customizing their tiered implementations to accommodate varying domain models, trust boundaries, batch operations, and optimistic concurrency management granularity. Following are the proposed methods, together with the authors’ summary of their purpose:

• ApplyOriginalValues() applies property values to original state of the entity
• ChangeObjectState() changes the state of the entity and incident relationships
• ChangeRelationshipState() changes state (new, modified, or deleted) of a relationship
• ChangeRelationshipState() (overload) changes state of a relationship represented by a navigation property
• ChangeRelationshipState<TSource>() changes state of a relationship represented by a lambda expression

The team presents simplified sample code for two scenarios:

1. General purpose Attach with state resolution delegate in which the client sends a modified entity graph to the mid-tier for processing and persisting.
2. ChangeOrder Service Operation in which the parent of a dependent entity is changed or added

I’m disappointed by the authors’ compromised approach to n-tier EF implementation, but I’ll reserve judgment until I can test sample code for both simple and very complex, tightly controlled scenarios with POCO entities at least as convoluted as those from AdventureWorks. Hopefully, the sample code will include a complete test suite with mocked data.

It will be interesting to hear the reaction to this approach from the ALT.NET petitioners, AKA the “NHibernate Mafia”, as well as that of the ADO.NET Advisory Council.

Update 11/21/2008: Frans Bouma’s Baby-sitter Framework 2.0: Change tracking in the EF v2, it's still your problem post takes the EF team to task for forcing developers to write their own n-tier change-tracking code. Frans points out that clients or employers should not be required (or requested) to pay for writing data access code. Ayende Rahien agrees with Frans in his Stealing from your client post of the same date. Ayende says “This Is Broken, By Design.” I agree.

Astoundingly, Jeff Derstadt said in a reply to Frans’ comment to the post:

One of our goals was to avoid defining a part[i]cular wire-level format for changes sent from client to another tier.

I’m no longer reserving judgment. This is Nuts! Not only must developers write their own client-side change-tracking code but kludge their own “wire-level format for changes sent from client to another tier.”

Hopefully Matt Warren will revive his mini-connectionless DataContext for LINQ to SQL or Danny Simmons will productize Perseus.

P.S. for Tim Mallalieu: We still haven’t seen the promised minutes of the Advisory Council’s first meeting.

Technorati Tags: Entity Framework,Entity Framework v2,Entity Data Model,EDM,POCO,persistence ignorance,concurrency management,ADO.NET Data Services,Astoria Project,REST