Rob Smyth

Thursday, 16 April 2009

Is Domain Entity Migration The Real Need?

'Data Migration' has always been a real 'challenge' in each project I've been involved in. Sometimes it is a seen as migrating application file format, other times database schema. I wonder if the perception does not match the need and hence ends up more complicated than necessary.

Where the file / database is used to persist an application's state or configuration, and not raw data to be processed, I'm thinking that they are presenters (aka UI forms) that happen to provide persistence. This perspective moves the focus to being able to migrate application objects, the file format is an 'end to means' rather than the objective.

The 'need' is to be able to restore an application's state. Maintaining some presentation of the that sate (ala file format) is one of multiple solutions and not the objective/need. These conversations so often come down to what we think is possible rather than what is needed.

I'm hoping to use this approach with NXMLSerialiser (to be known as NSerializer) so that migration can be supported independent of file format such as binary or XML. It is the objects that matter.

A snapshot of my current thinking:


public class VersionMigrationBuilder : IVersionMigrationBuilder
{
public void Build(IVersionMigrators migrators)
{
migrators.PriorToVersion(1, 2, 3).UseMigrator(new V010203Migrator());
migrators.PriorToVersion(1, 2, 2).UseMigrator(new V010202Migrator());
migrators.PriorToVersion(1, 2, 1).UseMigrator(new V010201Migrator());
migrators.PriorToVersion(1, 2, 0).NotSupported();
}
}

public class V010201Migrator : IMigrator
{
public void Build(IVersionMigrator versionMigrator)
{
versionMigrator.ForType("TypeNameA")
.RenameTo("TypeNameA_new")
.DiscardField("noLongerLovedField")
.RenameField("oldFieldName").To("newFieldName")
.SetNewField("newFieldName").To(42);
}
}


I'm keeping notes here.

No comments: