How to persist objects which implement the State pattern?

Question

I am new to the State design pattern and I can't find a proper example of saving different states of an object to the database (SQL Server in my case). The scenario is quite similar [almost identical] to the example described in the following article, however I have not found an applicable solution for persisting the states to the database. Can you guys recommend a link or possiblly give an example?

State Pattern Usage and Sample in C#

In addition: How do you enumerate all different ConcreteState types at run time? For instance, if you have 10 different states, do you declare an EnumStates with 10 different members and give every single ConcreteState member an associated EnumStates member, or you do get all the distinct states by getting the subclasses of ConcreteState?

For you information, I need to be able to search for entities based on their different states.

Answer 1

I didn't like the example you linked, below I listed the reasons:

1. I agree that the persisting architecture will be a mess - way to messy in my opinion.
2. Creating new instance per state seems to me like efficiency suicidal pattern.
3. Testing will be hell... finding errors will be hell.. debugging will be hell.
4. In over 30 years of experience I never seen this pattern being used even once in a data centric application - I did see it and used it in cases where I do not need to persist the information, in example when building a network layer - per port could be treated with that kind of state pattern.

I would go for this pattern instead:

pattern infrastructure

public interface IStateObject<T>
{
    T State { get; set; }
    void Process();
}

---

Example implementation for some pseudo Order object

public enum OrderState
{
    Taken,
    Approved,
    Payed,
    Emailed,
    BeforeShipment
    //etc.. etc..
 }

 public class Order : IStateObject<OrderStates>
 {
     //some linear fields of order..
     //: name, description, etc.. etc..

     public OrderStates State { get; set; }

     public void Process()
     {
         switch (State)
         {
             case OrderState.Taken:
                 // code to handle this state
                 break;
             case OrderState.Approved:
                 // etc..
                 break;
          }
         //persist myself to db.
     }
 }

It is very simple as you can save object per type per context of the object in one row.
Also an object is created once as intuitively it should have if we had no computer nears us..
But mostly because it is very straight forward and very flexible.

You might notice you actually may not need the IStateObject<T> at all - but I would argue you will need it later on when you want to process on vertical decisions. keep in mind that T doesn't have to be an enum. it could serve as common ground to evolve according to your app needs.

To further point out the mess I mentioned in the beginning of this answer,
Let's say we want to have history to previous states of the order:

Using the pattern offered in this answer - you add a PreviousOrderState property and now you have history per row.. And there are other ways I'm sure you can think of..

But using the "State Pattern" - you will be in serious problem... it will actually going to be complicated by a full "scale level" to do that.. you will have to be able to link from each type of table to each type of other table - or try to force Object Oriented on your database...

See my point? the States pattern is simply not designed for data centric apps.

Good Luck.

Answer 2

Don't try to translate the states into columns in a table, that wont work.

Instead serialize the states using JSON.NET as it supports inheritance. Then store it in a table like:

create table OrderStates
(
    OrderId int not null,
    Data nvarchar(MAX) not null
);

Include more columns if you want but only columns which is required to identify what the states are used for.

To activate the inheritance support in JSON.NET you have to use:

var json = JsonConvert.SerializeObject(yourState, typeof(StateBaseClass), JsonConvert.DefaultSettings)`. 
using (var cmd = sqlConnection.CreateCommand())
{
    cmd.CommandText = "INSERT INTO OrderStates (OrderId, Data) VALUES(@OrderId, @Data)";
    cmd.Parameters.AddWithValue("OrderId", orderId);
    cmd.Parameters.AddWithValue("Data", json);
    cmd.ExecuteNonQuery();
}

Same goes when deserializing, specify the base class when using JsonConvert.DeserializeObject().

How do you enumerate all different ConcreteState types at run time? For instance, if you have 10 different states, do you declare an EnumStates with 10 different members and give every single ConcreteState member an associated EnumStates member, or you do get all the distinct states by getting the subclasses of ConcreteState?

Subclasses. It's the only way to be able to introduce new states or remove old ones without having to modify the other classes. Each modification of existing classes can introduce bugs.