Is Persistence Ignorance Ignorant?

I’ve been reading and analyzing a lot of what people are saying about the Entity Framework and persistence ignorance. And I understand the general argument, which is, “Don’t clutter my domain model with persistence gunk.” What does that mean? No Load() methods in your classes, no attributes in your classes that “inform” the ORM layer (think [Column] attributes on your properties), no deriving from a common interface or base class (IEntity, ActiveRecord), and other similar things.

I’ve also looked at different ways to get the required information into the ORM. The most common approaches I have seen are:

Attributes
Mapping Files
In Memory or Class based Data Dictionary

In the end, an ORM needs this data dictionary to perform operations against the data source. The argument, from what I see, is all about where the data dictionary resides and how it is generated. It also seems to me that the bulk of the argument is focused on the testability of the resultant classes. Which, if you are practicing TDD, makes sense. But not everyone practices TDD (or wants to). So, if you remove TDD from the equation, does Persistence Ignorance still hold water or is it just over-engineering?

I do like the idea of using POCO’s and having “the magic happen” for me, but from what I’ve seen from the EF team is that this would require you to add the POCO to an ObjectContext that does the manual labor of tracking changes and some other stuff (I watched a short video on this a week or two ago but I can’t seem to locate it). But that adds development overhead as I now have to remember to add my POCO’s to the ObjectContext (or whatever it was).

When using Attributes, you are forced to rely on a lot of Reflection work, which is what I did recently. But as I read more about the Persistence Ignorance debate, I am wondering if the In Memory or Class based Data Dictionary model wouldn’t be a better approach? It would remove the reflection requirements which for large domain models can be costly.

I guess the good news is that I have the one method build up already, but I think what I am going to do is branch it and do an experiment with the In Memory / Class based Data Dictionary.

If someone out there has done all of this before and has some experience to share, I’d love to hear it.

Troy DeMonbreun Says:

November 11, 2008 at 3:23 pm

“So, if you remove TDD from the equation, does Persistence Ignorance still hold water or is it just over-engineering?”

My understanding as to the definition of “Persistance Ignorance” is to allow for the creation POCOs — objects devoid of any infrastructure trappings.

The main advantage of POCOs is the ability to change their backing data stores (different RDBMs, Web Services, REST, etc.) at a future time (or in real-time, for that matter) with no impact on the POCOs themselves.

Often, the idea is to have something like a Infrastructure Service spit out requested POCOs and store provided POCOs.

dotnetchris Says:

November 12, 2008 at 9:37 am

I feel the data layer should return POCOs. I loathe working with datasets and any other objects that have tons of semantic garbage in them because the DAL needs it to work right.

PI isn’t just for testability it’s also a key part of Domain Driven Development (DDD) there’s absolutely no reason your business layer should see all of these attributes or other code noise that is required to work with the ORM which is why POCOs are important for a data layer imo.