Using NHibernate for Legacy Databases

One of the downsides of being confronted with a shared legacy database day in and day out is that you have to map your domain objects to database tables that are also used by other applications. A typical scenario in this case is that those database tables contain more columns than those that are required for your application. These extra columns are specifically there to serve those other legacy applications. Heck, to make matters even worse, there are probably some new columns added specifically for your application as well. This is the fairy tale of shared legacy databases.

Using NHibernate in these scenarios can be challenging sometimes but its built in flexibility and extensibility really helps you to deal with those cases. The problem I ran into last week was that we needed to store a domain object into a table that had a lot more columns than were actually required for our application. If it would be possible to store null values in these columns or if they had default values configured for them in the schema, then this would not be a problem. Instead, these unnecessary columns could not store null values and had no default values associated with them.

First option would be to make some changes to the schema of the table. Alas, no luck there because the other legacy applications that are using the same table would break. Now what?

We needed to insert the default values ourselves, but those columns are not known by NHibernate because they are not mapped to any members of the domain object. One way to solve this, is to pollute the domain object by adding private fields that are initialized to the required default values.

public class SomeDomainEntity
{
    // Legacy fields with no purpose for the domain but required 
    // by the database.
    private Int32 _legacyField1 = 2;
    private Boolean _legacyField2 = false;
    private String _legacyField3 = "";
}

This is probably the simplest option, but imposes a broken window as infrastructure concerns are bleeding into the domain this way. In other words, this is not a viable solution. Keeping the legacy stuff isolated as much as possible, NHibernate provides some ways to deal with this by providing an extensive extensibility model.

After some snooping around in the source code of NHibernate, the solution we chose for dealing with this issue is by creating a custom access strategy. The built in property access strategies are probably already well known, but its also possible to write your own access strategy by implementing the IPropertyAccessor interface.

public class SomeDomainObjectAccessor : IPropertyAccessor
{
    private IEnumerable<IGetter> _defaultValueGetters;
    
    public SomeDomainObjectAccessor()
    {
        _defaultValueGetters = new List<IGetter>()
        {
            { new DefaultValueGetter<Int32>("LegacyColumn1", 2) }
            { new DefaultValueGetter<Boolean>("LegacyColumn2", false) }
            { new DefaultValueGetter<String>("LegacyColumn3", 2) }
        }
    }

    public IGetter GetGetter(Type type, String propertyName)
    {
        return _defaultValueGetters        
            .Where(getter => getter.PropertyName == propertyName)        
            .SingleOrDefault();
    }
    
    public ISetter GetSetter(Type type, String propertyName)
    {
        return new NoopSetter();
    }

    public Boolean CanAccessTroughReflectionOptimizer
    {
        get { return true; }
    }
}

private class DefaultValueGetter<T> : IGetter
{
    private readonly String _propertyName;
    private T Value { get; set; }

    public DefaultValueGetter(String propertyName, T value)
    {
        _propertyName = propertyName;
        Value = value;
    }

    public Object Get(Object target)
    {
        return Value;
    }

    public Type ReturnType
    {
        get { return typeof(T); }
    }

    public String PropertyName
    {
        get { return _propertyName; }
    }

    public MethodInfo Method
    {
        get
        {
            var method = typeof(BasicPropertyAccessor)              
                .GetMethod("GetGetterOrNull",
                           BindingFlags.Static | BindingFlags.NonPublic);

            var result = (BasicPropertyAccessor.BasicGetter)method              
                .Invoke(null, new Object[] { GetType(), "Value" });

            return result.Method;
        }
    }

    public object GetForInsert(Object owner, IDictionary mergeMap,
                               ISessionImplementor session)
    {
        return Get(owner);
    }
}

private sealed class NoopSetter : ISetter
{
    public void Set(Object target, Object value)
    {}

    public String PropertyName
    {
        get { return null; }
    }

    public MethodInfo Method
    {
        get { return null; }
    }
}

This simply involves a getter for providing default values and a dummy setter as we’re not interested in setting any values on the domain objects. The DefaultValueGetter class uses a trick so that we can keep using the reflection optimizer of NHibernate. This also seems to be necessary when using NHibernate Profiler.

Now we only have to provide some properties in the mapping of the domain object using our custom access strategy:

<property 
    name="LegacyColumn1"
    column="LegacyColumn1"
    not-null="true"
    type="Int32"
    access="SomeNamespace.SomeDomainObjectAccessor, SomeAssembly"/>
          
<property 
    name="LegacyColumn2"
    column="LegacyColumn2"
    not-null="true"
    type="Boolean"
    access="SomeNamespace.SomeDomainObjectAccessor, SomeAssembly"/>
          
<property 
    name="LegacyColumn3"
    column="LegacyColumn3"
    not-null="true"
    type="String"
    access="SomeNamespace.SomeDomainObjectAccessor, SomeAssembly"/>

This is probably not the best solution, but it does the job and prevents polluting the domain objects as a result of database quirks like these. I’m interested in hearing feedback or any better approaches.

Anyway, the easy extensibility of NHibernate makes it the best data access solution around. This way, one can deal with all edge case scenarios that weren’t anticipated by the framework builders.

Till next time