What's the correct way of retrieving my custom enumeration classes by their value?

I've created my own custom pseudo enumerations within my domain model to allow me to have some more verbose values. For example, my class is as follows:

public abstract class Enumeration<X, Y> : IComparable where X : IComparable
{

    public Enumeration(X value, Y displayName) { }

    public Y DisplayName { get { return _displayName; } }
    public X Value { get { return _value; } }

}

And a class that inherits it would be:

public class JobType : Enumeration<string, string>
{
    public static JobType ChangeOver = new JobType("XY01", "Changeover");
    public static JobType Withdrawal = new JobType("XY02", "Withdrawal");
    public static开发者_StackOverflow JobType Installation = new JobType("XY03", "Installation");

    private JobType(string jobTypeId, string description)
        : base(jobTypeId, description) { }
}

The problem I've got is that I want to be able to resolve these values from the value returned from the database in my repository. So I'm after a method such as:

public static JobType Resolve(string jobTypeId) { return matchingJobType; }

I started writing a resolve method for each enumeration class, but there's got to be a better way than duplicating the same method with a switch statement in each?

I thought about adding a Dictionary<X, Enumeration<X, Y>> Cache; property to the base class, and adding the class into it from the constructor of the base class. This would also have the benefit of ensuring unique values. The problem I have with this is that when I get the enumeration from the Dictionary, it's of the type Enumeration<X, Y> and I want it as a JobType.

So this means having to either add a third generic type to the Enumeration class and having:

public static T Resolve(X value); // With the additional type
public static T Resolve<T>(X value); // Or without an additional type

I obviously don't like the idea of having to write JobType.Resolve<JobType>(foo);, and what I want is just JobType.Resolve(foo);, but it should be done with as little code as possible. I.e. can all this just be handled from the base class without having to include an additional generic type?

This looks like a situation for the curiously recurring template pattern. If you want to get the base type method to return the derived class without casting, then you can pass the derived type into the base type, constraining the derived type to to be derived from the base type, e.g.

public abstract class Enumeration<TEnum, X, Y> : IComparable 
    where TEnum : Enumeration<TEnum, X, Y>
    where X : IComparable
{
    public static TEnum Resolve(X value) { /* your lookup here */ }

    // other members same as before; elided for clarity
}

You'd then define your concrete classes as follows.

public class JobType : Enumeration<JobType, string, string>
{
    // other members same as before; elided for clarity
}

Now your types will match up and no casting required on the base class Resolve method.

JobType type = JobType.Resolve("XY01");

How you store the value to instance mapping in the base class is up to you. It sounds like you already know how to do this anyway, and just needed a bit of help with getting the types to match up.

Your real enumeration class may be more complicated than this, but your current implementation looks like it could be defined much more simply as a standard enumeration coupled with a DAL pattern, or simply a dictionary:

public enum JobType
{
    ChangeOver,
    Withdrawal,
    Installation,
}

// Maybe inside some DAL-pattern/database parsing class:
var databaseToJobTypeMap = new Dictionary<string, JobType>()
{
    { "XY01", JobType.ChangeOver },
    // ...
};

Keeping the parsing code together (maybe with an interface abstraction) gives you the option to switch parsers when your data storage format/needs change, or if you end up having multiple data sources.

If you need to parse the actual JobType values (for example, the string "ChangeOver" or an integer representation), then you can use Enum.Parse/Enum.TryParse, or casting.

The implementation you have seems to be more inflexible, because it locks the enumeration type to one dictionary mapping style/representation.