Persistence Ignorance Is Bliss, but Is It Missing from the Entity Framework?

A brief item that appeared yesterday afternoon in Danny Simmons's system.data.objects dev guy blog led me to the March 13, 2007 "Persistence Ignorance in the Entity Framework" post by Chris Moore (a.k.a. NTDeveloper) in the ADO.NET Orcas forum. The post is a copy of a March 8, 2007 comment to Shyam Pather's "Using Stored Procedures for Change Processing in the ADO.NET Entity Framework" post in the ADO.NET Team blog.

One of the primary features of object/relational mapping (O/RM) tools, such as the Entity Framework, is persisting domain object (entity) instances as rows in relational database tables. Jimmy Nilsson*, the author of Applying Domain-Driven Design and Patterns: With Examples in C# and .NET, defines the term persistence ignorance (PI) as a property of "ordinary classes where you focus on the business problem at hand without adding stuff for infrastructure-related reasons. ... The classes should focus on the business problem at hand. Nothing else should be in the classes in the Domain Model."

Chapter 6, "Preparing for Infrastructure," of Nilsson's book states on page 184:

[I]f you use a PI-based approach for persistent objects, there’s no requirement to do any of the following:

• Inherit from a certain base class (besides object)
• Only instantiate via a provided factory
• Use specially provided datatypes, such as for collections
• Implement a specific interface
• Provide specific constructors
• Provide mandatory specific fields
• Avoid certain constructs
• [W]rite database code, such as calls to stored procedures

The preceding language implies that requiring any of the above elements prevents implementing an object persistence layer that qualifies as persistence ignorant.

Chris takes the following issues with the ADO.NET 3.0 Entity Framework's implementation in the Orcas March 2007 CTP:

1. Entities must subclass the Entity framework class, and
2. It is necessary to attach various attributes to entity properties.

Both of which violate Nilsson's PI principles.

Kevin Hoffman, who has compared the August 2006 CTP of the .NET Entity Framework with Ruby on Rails' ActiveRecord, adds his PI objections in this shortened entry:

Getting us "partly there" seems to be a big theme in the Entity Framework. Virtually all of the features that I like about the EF are about 75% of what I want them to be. One such feature is Persistence Ignorance. In a true entity model, I should, in theory, be able to take the model of my entities, complete with ability to create a runtime graph of that model - and go and load data from 3 different stores (XML, Access, or SQL Server) and not change a single line of code. [Emphasis added.]

Microsoft describes the Entity Framework/Entity Data Model as an OR/M—not a domain model management (DMM)—tool, so expecting the capability to substitute an arbitrary XML storage schema for a relational schema is asking a bit much, in my opinion. (Typed DataSets handle persistence to XML files reasonably well, although not in the same way as an O/RM tool.) Substituting Access, Oracle or DB2 for SQL Server would require specifying the appropriate OLE DB provider by changing connection strings. In this case, you'd lose the performance advantages of .NET managed providers for all but Access (Jet) databases. However, it's unlikely that anyone would use compatibility with Jet databases as a criterion for choosing an OR/M tool.

According to Danny Simmons' forum answer to Chris and Kevin's post (abridged):

1. The requirement that entity classes inherit from a single base class: This is a restriction we are actively working on removing, and in a future CTP you will be able to create your own data classes which do not inherit from one of our framework classes but instead just implement a set of interfaces that define the minimal functionality required for successful interaction with the framework.
2. The requirement to attach attributes to properties on your entity objects: The long-term idea is to have two separate opportunities for abstraction: First, there is the mapping provided by EntityClient which separates your conceptual model from the store format. The second abstraction opportunity is between the data classes (your objects) and the conceptual schema. For Orcas we have scoped the problem down and require that the mapping at this layer be 1-to-1.

It is true that we don't allow complete persistence ignorance in that we don't support true, plain-old-CLR objects [POCO] with absolutely no knowledge of persistence--you have to expose to the framework which properties and classes actually need [to be] persisted.

Jimmy addresses the issues of .NET attributes in a note on page 188:

Something that has been discussed a lot is whether .NET attributes are a good or bad thing regarding decorating the Domain Model with information about how to persist the Domain Model.

My opinion is that such attributes can be a good thing and that they don’t really decrease the PI level if they are seen as default information that can be overridden. I think the main problem is if they get too verbose to distract the reader of the code.

Danny says in his 3/13/2007 blog post:

Unfortunately I don't have the time right now to write up a full treatment of this subject, but it's important, and it just came up in the Orcas ADO.Net forum. I took a quick stab at it in a response to a question there, and I don't want to lose track of this idea for future treatment.

and in a 3/15/2007 forum post:

It's my intention to try to write up a fairly detailed response because this is such an important topic. Unfortunately I'm driving hard toward a deadline right now so this is going to have to be delayed a few days. I just wanted to let you know that I haven't forgotten, and I will respond.

I'm looking forward to Danny's "future treatment" as well as commentary by .NET O/RM competitors: Frans Bouma (LLBLGen Pro), JBoss/Redhat (NHibernate), Mats Helander (NPersist), Paul Wilson (WilsonORMapper) and others.

Note: Paul offers downloads of his LINQ and O/R Mapping presentation and introductory ORMapper and NHibernate examples.

Major Update 3/16/2007: Sam Gentile's ADO.NET 3 - Entity Framework without Persistance Ignorance post quotes Ayende Rahien's post of almost the same name that take's Microsoft's ADO.NET Team to task for ignoring (or failing to fully support) Persistance Ignorance. (Be sure to read the comments, especially about designers and generated code.) Sam says that he and and his cohorts (Jeremy Miller, Scott Bellware, Jeffery Palermo, raymond lewallen, Jean Paul Boodhoo and James Kovacs) plan to teach the team about NHibernate at the Most Valuable Professional (MVP) global conference (Microsoft 2007 MVP Global Summit) this week.

Jeffrey Palermo (C# MVP) says in his Linq to Entities: Microsoft's first go at O/R Mapping (they need our feedback now!) - level 300 post:

I have email addresses for several people on the team, and I'll be letting them know what is so compelling about NHibernate and why the above issues have to be resolved before RTM and not after. ...

I want Linq to Entities to succeed. I want frameworks and tools to continually get better; therefore, I will be communicating with the product team to voice my strong concerns over the current direction.

Of course Entity Framework/LINQ to Entities isn't "Microsoft's first go at O/R Mapping." That was ObjectSpaces, which died in the Whidbey (VS 2005 beta) era. Click here for previous OakLeaf posts obout the rise and fall of ObjectSpaces and see, especially, The Language Integrated Query (LINQ) Project (September 2005).

In a 3/16/2007 comment to his LINQ to Entities post, Jeffry says:

I don't think there is any documentation yet, just the bits. I spoke with the Entity Framework architects today, and the roadmap is actually quite bright, so I'm less concerned now. I think they are on the right track, but it will take a while, so don't expect to have your domain-centric O/R mapper in Orcas. I'm not sure what I can disclose, but I'll find out and blog an update.

You can watch Channel9's "ARCast - NHibernate" segment with NHibernate expert Ben Day. Ben will present "Building ASP.NET Database Applications with NHibernate" at 1005 Media's VSLive San Francisco and VSLive Orlando.

Jeff Perrin weighs in with a Persistence Ignorance post and a link to an 2005 O/R Mapping: Attributes vs. XML For Mapping entry that connects to Steve Eichart's If Attributes are good enough for Indigo why aren't they good enough for O/R Mappers? post. Steve discusses the [DataContract] attribute that Indigo (WCF) now shares with ADOEF and Chris Moore wants removed or made optional. According to Danny, they are present to help automate WCF serialization and are optional.

Update 3/16/2007: Minor edits and a brief addition.

Note: Mats' Attributes In NPersist post describes a new NPersist feature that enables substituting attributes for metadata in ObjectMapper's XML files. NHibernateEg provides a method for substituting .NET attributes for NHibernate's .hbm.xml files.

* Jimmy Nilsson is a widely respected .NET and database developer with 20 years of experience. He owns and runs the Swedish consulting company JNSystemKonsult AB. In addition to Applying Domain-Driven Design and Patterns: With Examples in C# and .NET, he wrote .NET Enterprise Design with Visual Basic .NET and SQL Server 2000 in 2001. He's also written numerous technical articles and is a well-known trainer and conference speaker. His "current pet project is called NWorkspace and is (or, at least, might become) what I call adapters for different persistence solutions. Nope, it's not another OR Mapper for .NET, which might come as a shock! Instead, what NWorkspace does is try to reuse the functionality of the current OR Mappers." He now says that LINQ is a better NWorkspace—"I quite often receive enquiries about when I'm going to publish NWorkspace, but I'm still hesitant to do so as it's definitely not of publishable quality. Yet it occurred to me that to a great extent LINQ is largely what the vision of the querying part of NWorkspace was all about. Of course LINQ is way, way better and way more complete. "

Update 3/28/2007: Danny Simmons says there will be A delay before I write more about persistence ignorance... so he can more carefully consider his reply. Danny also posted Change Tracking Mechanisms for the Entity Framework, which covers alternative approaches to change tracking, which is based on values designated "concurrency tokens."

C# MVP Scott Bellware contributes Entity Framework Challenges, an essay arguing against the data-centricity of the current Entity Framework design:

When I work with the Entity Framework I feel trapped in a data guy's perspective of what a framework for behavioral business objects should be.

An entity from the perspective of a data guy is a chunk of data; something that is loosely akin to a row in a table or a row in a view (although that's a bit of an over-simplification). To an application programmer working with entity-centric code, an Entity is a chunk of behavior that can also hold on to its data. ...

The Entity Framework must undergo significant change before it no longer presents impediments to behavior-driven development practices for behavior-centric objects. The framework is an important step forward for the Microsoft data access strategy, but it's only a baby step forward in terms of the frameworks, practices, and expectations that Microsoft customers already have. ...

I'm still committed to the Entity Framework, but it's frustrating to have to turn back the clock on some of the more effective practices that my team has for ensuring success with application-level entity programming. I hope that more interaction between the Entity Framework team will bring about a framework that allows for and even enhances contemporary application development practices in .NET.

I wonder if Scott will remain that committed to the Entity Framework if the EDM Designer doesn't arrive by Orcas RTM.

Another C# MVP, John Papa, argues in Entity Framework Thoughts:

In its current state the Entity Framework can be generated from an existing data model (or can be created by hand with XML). The data team at Microsoft knows this is a limitation and is working on solutions to make building and tweaking entities, mapping the conceptual model to a logical model, and overall design of the EDM much more fluid. I am very excited about seeing what they produce on this end.

Be sure to read the flurry of comments that ensued.

Here's an early (9/13/2006) ADO.NET Team post by Atul Adya that explains Entity Mapping in ADO.NET vNext in considerable detail and discusses the View Generator (a.k.a. Mapping Compiler), Mapping Views, and Query Mapping (QM) views, which refers to an earlier Queries in ADO.NET vNext post by S. Muralidhar (Murali).

The Last Word (4/24/2007) on the Entity Framework discussion at the MVP Summit by Jeremy D. Miller: LINQ for Entities is NOT the O/R Mapper I want today, but might be if and when they... is the best and most reasoned exposition of the current issues developers have with LINQ to Entities and the Entity Framework: "[T]he intrusiveness of Linq for Entities into your Domain Model classes, the general clumsiness of the configuration model as it is right now, and the mechanisms for tracking object state." Be sure to read the comments and then check out Scott Bellware's On Being the "NHibernate Mafia" post.

Technorati tags: Entity Framework, Entity Data Model, Orcas, Orcas March 2007 CTP, O/RM, Object/Relational Mapping, Persistence Ignorance, NHibernate, NPersist, LLBLGen