tags:

views:

376

answers:

2

When do Enumerations break down?


To support a new feature in an existing system, I was just considering implementing some form of discriminator to an entity table in my database schema.

In wanting to begin by doing the least thing that will work I first of all decided on an integer column and a C# enum at the business entity layer for the sake of readability. This would provide the poor-man's polymorphism that may eventually grow into an actual polymorphism and perhaps towards a Strategy pattern.

I decided to consult the blogosphere as I've never been entirely comfortable with using enums - I wondered, should I skip the enum and go straight for a struct or a class?:

First of all I found an assertion that 'Enums are Evil', but I felt this was an over-generalization which does not directly address my use-case.

If I do go for an enum then there's a good discussion of how I can extend my mileage by adding extra metadata to my enum.

Next, I came across Jimmy Bogard's discussions of Enumeration Classes and further discussed in 'Strategies and discriminators in NHibernate'

Should I skip the enums and go straight for Enumeration Classes? Or does anyone have any other suggestions for how to add a simple entity discriminator to my domain model.

Update:

I'd also add that both NHibernate and LINQ to SQL (and probably all other ORM-related data-access methods) make the use of enums very enticing as they let you map a discriminator column transparently in the mapping.

Would it be as easy to map an Enumeration Class?

Related questions:


Disclaimer:

Despite my careless use of the term entity (with a lower case 'e') I don't claim to be discussing DDD here...

+1  A: 

Those Enumeration Classes look neat, I've often looked jealously at Java's enums.

I think the usual rules apply: do the Simplest Thing That Could Possibly Work. If you find yourself with more than one switch on the enum, then that's a smell, and time to consider the pattern you've found.

Otherwise, why burden yourself with something you don't need?

Jeremy McGee
+1  A: 

Today enums are evil, tomorrow OOP might be evil and AOP will be fine.

Just use the right tool for the job. Remeber, Keep It Simple...

If the enum is just for the sake of telling the type of an object - don't bother, use it.

If it has some business logic in it, than it is probably another class.

Dmytrii Nagirniak
The problem with starting simple is that if I use an Enum my 'foreign key' is an integer. If I later refactored to the disriminator being a full first-class entity (albeit just a lookup table) then I might wish that the foreign key had been a GUID (which happens to be the 'standard' we use for keys in our schema.
rohancragg
Then map Enum as a guid. Just think if you really need it NOW. If not, just Keep It Simple.
Dmytrii Nagirniak
OK, fine. But if, by that point, I have some legacy of data then I have some pretty non-trivial database refactoring to do.
rohancragg
What if you wont? You will maintain more complex solution during the application lifetime. So introduce complexity if you KNOW it is needed.
Dmytrii Nagirniak
Ironically I decided to deviate from the 'standard' because this is a lookup not an entity so it seemed to make more sense having an integer PK instead of a GUID (which the DBAs hate anyway). I feel a whole new question coming on regarding the modelling of lookups vs entities... :-)
rohancragg