I don't understand the point of persistence independence [duplicate]

Question

Possible Duplicate:
What are the benefits of Persistence Ignorance?

After some time and some questions trying to figure out the entity framework, I've come to the conclusion that I just don't get what the point of persistence ignorant objects is.

As best as I can tell, the practical difference between using persistence-aware objects and persistance-ignorant ones is that one gets used something like

Person p = Person.Load(id);
p.Active = false;
p.Save();

and the other is used along the lines of

using (var context = new MyContext())
{
   Person p = context.Persons.Single(x => x.ID == id);
   p.Active = false;
   context.SaveChanges();
}

In the first case, I can return p, and call Save() at some later point. In the latter, I could return p, but I'd need to put it into a new MyContext() to save it. In the first case, assuming that Person inherits Load() and Save() from some base object which actually handles the database logic, if I wanted to change the persistence, it would just involve changing that base object (or even just have an IPersistent interface which multiple base classes can implement to access multiple stores). In the latter, I would need to change every instance of MyContext if the persistence layer changed, and it would be hideously complicated to do piecemeal.

My impression is that persistence-ignorance is a good thing. I just can't understand why. It seems like it's much more complicated to set up, work with, change wholesale and change piecemeal, with no advantage for that complication. Am I just missing something important, or is my entire understanding of what persistence-aware/ignorant means flawed?

Answer 1

Persistance Ignorance is part of Seperation of Concerns. You should ask yourself, why should Person know how it should be loaded or saved? Person should deal with its own little domain.

PI means that Person doesn't care if it comes from memory, SQL, flat binary or any other means of Persistance and allows you at later point to replace your persistance layer to something else. You might initially develop your application to use flat binary files with the basic serializers to store data. Later, you might upgrade to SQL for performance reasons-- and this change is only needed in the one location whose -job- it is to handle persistance, the associated layer/component. Otherwise you must go through your entire code base to change little parts here and there that deal with persistance.

Answer 2

Just to speak about your example, by writing Person.Load(id) you're saying - load this object by looking at his identifier - you're creating a rigid factory pattern, by wich you can only get objects if you know their ID, later you'll find out that you need to extract records based on some search criteria, and you'll add more factory methods whereas the second solution already gives you all the freedom you need.

The second solution is perfect to switch the persistence logic at runtime, since it is decoupled from the object model, you could theorically decide wich persistence engine to use inside your client code, without hardcoding and touching your OM, and it's false to say you would need to change every instance of MyContext, you should write your client code to let it receive the context from a sort of factory class or dependency injection.

As an example you could have this pseudocode:

var person = onlineDbContext.Persons.Single(x=>x.Guid == myguid);

offlineDbContext.Persons.Add(person)
offlineDbContest.SaveOrUpdate();