Background: I have seem some argument for using enumeration classes instead of enum in C#, in particular, this section from a book available at MSDN. On the references there is this "Enums are Evil" article which in turn makes quite a good point on the matter.

One of the reasons quoted is particularly convincing:

Imagine the following phone call between Frank, a customer, and Darren the developer:

Frank: Hi Darren; I need a new value for the person status about his financial standings. We have currently Low, Medium and High, but we need ‘undefined’ as a new value.

Darren: I see.

Frank: When can you implement that?

Darren: Uups Frank. We just finished our sprint this week. The earliest we can plan this is for the sprint after the current one. That takes about 5 weeks.

Frank: What? It’s just another value not a whole new functionality!

Darren: Calm down Frank; we have these cool enum’s in place that saved us a lot of development time. To extend them I have to add it in the code and create a new build. We have to plan it for the next sprint.

Frank: Are you nuts? I don’t know what you talking about. I’m an ordinary user and just want to have another value on the user interface.

Darren: Sorry for that. I can’t do it earlier.

I've been through that already and it really feels like it is much more natural to allow the user to persist to the database the values he uses, like CardTypes as shown in the first MSDN link I provided:

public class CardType : Enumeration
{
    public static CardType Amex = new CardType(1, "Amex");
    public static CardType Visa = new CardType(2, "Visa");
    public static CardType MasterCard = new CardType(3, "MasterCard");

    public CardType(int id, string name)
    : base(id, name)
    {
    }
}

The problem: All of this is fine, and using these "enumeration classes" instead of enum has a lot of advantage. But now suppose the user comes and says that there is some specific rule for a specific item on the enumeration (for example, there is a very specific rule just for the Visa card).

With enums this is fairly easy. We would just perform a very natural check if (cardType == CardType.Visa). The point is: the values are all there on code to be checked.

But with enumerations the values are dynamical and added by the user. So the best I could consider would be to check for a string, querying the database's table containing the enumeration values for the specific item.

But I think this is too error prone - say the user alters the string for that enumeration, the query wouldn't work anymore. Further if the user made any typo when writing, it also wouldn't work.

Is there some better method?

In summary: if we use enumration classes instead of enum and if there is a business rule for a specific item that the user is adding dynamically, how can we verify and address that in a more reliable way than "checking a string"?