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
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()
{
{ "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.