R – Can Persistence Ignorance Scale

Let me explain this with an example. Lets assume your are implementing an application using a classical SQL approach. You open recordsets, change data and commit it.

Pseudo code:

trx = connection.CreateTransaction();
query = connection.CreateQuery("Select * from Employee where id = empid");
resultset = query.Run();
resultset.SetValue("Address_Street", "Bahnhofstrasse");
resultset.SetValue("Address_City", "Zürich");
trx.Commit();

With NHibernate it would look something like this:

emp = session.Get<Employee>(empid);

// persistence ignorant 'logic'
emp.Address.Street = "Bahnhofstrasse";
emp.Address.City = "Zürich";

session.Commit();

Persistence Ignorance means that the business logic itself doesn't know about persistence. Or in other words, persistence is separated from logic. This makes it much more reusable.

Move 'logic' to a reusable method:

void MoveToZuerichBahnhofstrasse(Employee emp)
{
  // doesn't have anything to do with persistence
  emp.Address.Street = "Bahnhofstrasse";
  emp.Address.City = "Zürich";
}

Try to write such a method using resultsets and you know what persistence ignorance is.

If your are not convinced, see how simple a unit test would be, because there aren't any dependencies to persistence related stuff:

Employee emp = new Employee();
MovingService.MoveToZuerichBahnhofstreasse(emp);
Assert.AreEqual("Bahnhofstrasse", emp.Address.Street);
Assert.AreEqual("Zürich", emp.Address.City);

DDD is something different. There you build up your domain model first (class model) and create the database design according to it. With NH this is very simple, because - thanks to persistence ignorance - you can write and unit test the model and logic before having a (definitive) database model.

Testing: We are testing mappings by creating an instance of the entity, storing it to the database, getting it back and compare it. This is done automatically with lots of reflection. But you don't need to go so far. most of the typical errors show up when trying to store an entity.

You could do the same with queries. Complex queries deserve a test. It's most interesting if the query gets compiled at all. You don't even need any data for this.

For database integration tests, we are using Sqlite. This is pretty fast. NH produces the in-memory database on the fly using SchemaExport (before each test).

I would claim that, like most things, its a sliding scale. There are things that we make that want to have the property of persistence. On one end of the scale is this thing having all of the guts, dependencies, and code that is custom built to persist just this one thing in its particular way. On the other end of the scale is something that just magically happens, all without us doing much more than adding a token or setting a property somewhere that causes that thing to 'just persist'. In order to get to the magical side of the scale, there are frameworks, design guidelines, conventions, etc that assist the magic in happening. I think you could argue that a tool could be produced that had fewer requirements and restrictions than NHibernate but pursued the same goal; that hypothetical tool would be further along our scale.

I don't know that I like the term 'persistence ignorance' so much; its really about an object being ignorant of the implementation, the backing store, the cache, that sort of thing - an object is typically aware of whether or not it is persistent, though. But that's just semantics.