Recently, I needed to change a basic enumeration into a full-fledged state pattern. After getting all my domain classes updated, I began reviewing the persistence layer. And I hit a wall. I wasn’t sure how I wanted to update my Fluent NHibernate convention to persist the current state.

My original classes were similar to this:

public class MyProgress{ 
   public virtual Guid Id { get; set; }
   ...
   ... 
   public virtual MyStatus Status { get; private set; }
}

public enum MyStatus{ 
   New, 
   InProgress, 
   Completed, 
   Canceled, 
   Failed
}

My new state pattern was similar to this:

public abstract class MyStatus
{
    public static readonly MyStatus New = new NewStatus();
    public static readonly MyStatus InProgress = new InProgressStatus();
    ...
}

public class NewStatus: MyStatus
{
    public override void Start(MyProgress progress)
    {
        progress.SetStatus(InProgress);
    }
    public override void Cancel(MyProgress progress)
    {
        progress.SetStatus(Cancelled);
    }
    public override void Fail(MyProgress progress)
    {
            progress.SetStatus(Failed);
    }
}
...

Here is the problem: My enumeration was persisted as an integer field on the record. Now that I had a state pattern, how should I save my state? I googled the problem and found Derick Bailey’s article on the state pattern and Fluent NHibernate. Derick’s pattern works well, but I felt that creating a lookup table in my database just so I can persist a value in another table was not the path I wanted to traverse – I wasn’t persisting an entity, I was persisting a state value on an entity. Not finding any more love from Google, I asked around and was advised to contact fellow Elegant Coder and Guild3 member, Jason Grundy. Here is Jason’s advice:

“I’ve recently changed from using Enums to an approach outlined by Jimmy Bogard here. In the Entity I would do something like this:

protected int _orderStatusId;
public virtual OrderStatus OrderStatus
{
    get { return Enumeration.FromValue<OrderStatus>(_orderStatusId); }
    set { _orderStatusId = value.Value; }
}

Then in Fluent NH you can simply map to the protected member.”

I decided to pursue Jason’s advice.  The result is my database tables did not need to change at all. Here is some snippets of the updated classes:

public class MyProgress
{
     public virtual Guid Id {get;set;}
     ...
     protected int _status;
     public virtual MyStatus
     {
         get{ return Enumeration.FromValue<MyStatus>(_status); }
         set{ _status = value.Value; }
     }
     ...
}
 
public class MyStatus : Enumeration
{
     public static MyStatus New = new NewStatus();
     ...
 
     private class NewStatus : MyStatus
    {
         public NewStatus() : base (0,"New"){}

         public override void Start(MyProgress progress)
         {
             progress.SetStatus(InProgress);
         }
    }
     ...

Notice that the MyStatus class is no longer abstract. However, the subclasses are all private nested classes, each with a value and a display name. I set each subclass value to match the enumeration value it replaced. I did not need to convert my existing data to a new schema.

And here is the Fluent NHibernate override:

public class MyProgressOverride : IAutoMappingOverride<MyProgress>
{
    public void Override(AutoMapping<MyProgress> mapping)   
    {
        mapping.Map(x => x.Status)
            .CustomType(typeof(int))
            .Access.CamelCaseField(Prefix.Underscore);
    }
}

As you can see, we use convention-based automapping with overrides, but this same map could be used in a standard class map.

Thanks to Jimmy, Derick, and Jason for the inspiration and assistance!