2

I've added enums to my C# Entity Framework 6, MVC 4 application. I like the approach as:

  1. I think my model is clear that the value comes from a lookup.
  2. I can easily bind them to a select list in my view using approached such as these: examples from Stack Overflow.
  3. I'm not looking up the database to get the values.
  4. I have less plumbing code to use the values.

On the downside, I'm thinking that:

  1. I need to be careful to keep my database in sync with my code for actual lookup tables.
  2. I guess, I would need to deploy the code every time I make a change to one, instead of perhaps having 'administration' tables where a user could add new lookup values. (I guess you could be selective and not use enums for values that would change a lot).

I'm just wondering what the real advantages of this approach are and if there are common scenarios when I would want to avoid it?

Thanks

Community
  • 1
  • 1
davy
  • 4,474
  • 10
  • 48
  • 71
  • 1
    Never. Your binding code to database. Might seem like a nice thing now but in a team environment that is a disaster waiting to happen potentially. Having to re-deploy when data changes in the database is horrible. – Jammer Feb 23 '14 at 16:06
  • 1
    Thanks Jammer, yeah I'm coming way to this way of thinking. – davy Feb 24 '14 at 13:47

1 Answers1

1

I don't think your question is related to EF at all, it's more backend-agnostic.

The only real problem is what you have already suggested - having to recompile when you need to add/remove values. However, that all really depends on how often you actually expect the list to change.

The point of using an enum is for readability & simplicity from the developers perspective, however, if you enum is really just for UI purposes I'd argue that you could end up giving the developer more work in maintaining the list than doing a lot of work once and not having to worry about it again.

Having to re-compile just for the sake of adding a new option for a user seems very brittle to me.

James
  • 80,725
  • 18
  • 167
  • 237
  • Thanks James, yeah I agree. I think I'll use his approach sparingly, fro very static lists (if at all). – davy Feb 24 '14 at 13:46
  • 1
    I really wouldn't use it all. The problems are myriad and well beyond the scope of a comment. Also whilst it is good practice to only develop to known requirements one shouldn't preclude future requirements and paint yourself into a corner that will be difficult, potentially error prone and expensive to change later when requirements change. – Jammer Feb 24 '14 at 14:06
  • @Jammer your more than entitled to your opinion, however, in my opinion, future proofing is a second priority; getting the thing working is *always* the first priority and if using an `enum` does that then by all means use it. However, I agree (as my answer suggests), you do need to weigh up the future implications of what you are doing and whether or not it's going to be worth it in the long run. That's why I am not necessarily suggesting not to do it, because in reality it will do the job...rather, having a think about it before you do. – James Feb 24 '14 at 14:42