简体   繁体   中英

C# Enums vs Data driven lists

I am trying to figure out the best way to go about my design for an enum. Let's say I have a class and enum:

public enum ActionType
{
    Acceptable = 1,
    Unacceptable = 2,
    PendingReview = 3        
}
public class Report
{
    public ActionType Action { get; set; }
}

Let's say I also have a database table that stores the different action types:

Id     Action
1      Acceptable
2      Unacceptable
3      PendingReview

if I want to add another type of action at a later day I would have to update the enum and redploy the assemblies. But I love the way enums reduce errors, make code easier to read and the ensurance of forward compatibility. What is an efficient way of hadeling new action types?

Thanks!

If the value indicates a change in program flow you'll want it to stay as an enum. Just store the numeric value in a table field.

If the value does not change program flow, then having a lookup table where the potential values are pulled from the database is a better way to go.

It sounds like your's falls into the first category. At which point you'll have to deploy the code when adding options anyway in order for the app to know what to do with the new options.

There's a middle ground. Take a look at log4net.Core.Level (from log4net, naturally) for an example of a class that lets you create something which looks a lot like an enum but isn't.

Look here .

I also have had the same problems as you have and have tried to use enums as much as possible because it make readability quite a bit easier.

The approach I have used is somewhat redundant, however I have created a lookup table and have used a mirror enum in the code. The problem with just using the enums is you will have statuses saved in the DB that are confusing such and have to be discerned from the documentation. The problem with the DB only approach is the code readability is seriously hampered and you will have totally unreadable statements like if (status == 2) ...

Also, if an enum item is added then program flow will change and the code will have to be updated anyways. This makes it pretty irrelevant. Deployment strategies like ClickOnce make deployment almost trivial.

We definitely have this challenge in the project I'm working on. For us, the benefit of using enums in terms of readability outweighed the maintenance and so we just tried to find a way to check ourselves and raise a flag when something didn't get properly updated.

The solution we use is that we have unit tests that run after each compile to validate the members of the enum and their backing values against the database table that is associated with that enum.

One of those unit tests might look like this:

[TestMethod]
public void SomeLookupTest()
{
    LookupGetter getter = new LookupGetter();

    LookupTester.CompareEnumWithDatabase(
        getter.GetItems(LookupName.Schema__SomeLookup),
        typeof(SomeLookupEnumType)
    );
}

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM