Loading enumerations from database

I have a problem with mapping .NET enumerations to database tables. Imagine I have a table called Statuses with the following values:

StatusID | Name

1 Draft

2 Ready

...

...

In the application layer, I can either use a Repository to get all Statuses as an IList object. However, the problem with this approach is that I cannot reference a certain status in my business logic. For example, how can I implement something like this?

if (myObject.Status is Ready)
    do this
else if (myObject.Status is Draft)
    do that...

Since the statuses are loaded dynamically, I cannot tell for sure what particular Status object in the List represents the Draft or Ready status.

Alternatively, I could just use an enumeration like

public enum Statuses
{
    Draft, 
    Ready
};

Then I could easily use an enumeration in my business logic.

if (myObject.Status == Statuses.Draft)
    // do something..开发者_StackOverflow中文版.

However, the problem with this approach is that every time the user wants to modify the list of Statuses (adding a new status, or renaming an existing status) the application has to be re-compiled. We cannot load the statuses dynamically from the database.

Has anyone else come across a similar situation? Any solutions/patterns?

Cheers,

Mosh

A common way to do this is to have your enumeration specified in a common low level assembly that can be referenced by any other assembly (every project i've ever worked on has some sort of Framework or Common assembly).

In your definition of the enum, you can specify actual values:

public enum Status 
{
    None = 0,
    Draft = 1,
    Ready = 2
    ... etc ...
}

Do not be concerned about the need for recompilation if a status value is added. If that status value is actually going to be used then you will have to add new code anyway (why do you care about a new status value if your code is never going to make decisions based on it?). So somewhere in your code you will have something like this:

if (myObject.Status == Status.MyNewValue)
    ... carry out some action ...

and the assembly containing this code will need to be recompiled, as will the common assembly where the enum is defined (so that the new value can be seen from the assembly this code is in). The database people can create as many Status values as they want, if you don't specifically use them then you don't need to recompile. Of course there are exceptions to this rule - because an Enum is by default an int you can read in any status value from the database and assign it to your Status property, but it will fail serialization if you have not explicitly defined that status enum value in your enum definition.

So to make a long story short: don't worry about the recompilation aspect, just do it - your status values won't change that often :)

Also, if you are worried about the name of the enum value, then that can be addressed by mapping enum values to strings in a resource file, that string is what you show in your data grid or anywhere else the enum is surfaced through the UI. If you business specialists are changing the definition of the enum though (like '1' now means 'Ready' and '2' now means 'Draft') then that is just plain silly and they shouldn't be doing that - if they are then you will have to refactor your code anyway.

For me the enumeration solution has worked well. The addition of a new Status to the database means that the application will probably have some more work to do when it encounters it. For example, what would happen if I added a Published or Deleted status.