tags:

views:

97

answers:

3

I've run into this issue quite a few times and never liked the solution chosen. Let's say you have a list of States (just as a simple example) in the database. In your code-behind, you want to be able to reference a State by ID and have the list of them available via Intellisense.

For example:

States.Arizona.Id  //returns a GUID

But the problem is that I don't want to hard-code the GUIDS. Now in the past I've done all of the following:

  • Create class constants (hard-coding of the worst kind.. ugh!)

  • Create Lookup classes that have an ID property (among others) (still hard-coded and would require a rebuild of the project if ever updated)

  • Put all the GUIDS into the .config file, create an enumeration, and within a static constructor load the GUIDS from the .config into a Hashtable with the enumeration item as the key. So then I can do: StateHash[StatEnum.Arizona]. Nice, because if a GUID changes, no rebuild required. However, doesn't help if a new record is added or an old one removed, because the enumeration will need to be updated.

So what I'm asking is if someone has a better solution? Ideally, I'd want to be able to look up via Intellisense and not have to rebuild code when there's an update. Not even sure that's possible.

EDIT: Using states was just an example (probably a bad one). It could be a list of widgets, car types, etc. if that helps.

+1  A: 

Personally, I would store lookup data in a database, and simply try to avoid the type of hard coding that binds rules to things like individual states. Perhaps some key property of those states (like .ApplyDoubleTax or something). And non-logic code doesn't need to use intellisense - it typically just needs to list them or find by name, which can be done easily enough however you have stored it.

Equally, I'd load the data once and cache it.

Arguably, coding the logic against states is hard coding - especially if you want to go international anytime soon - I hate it when a site asks me what state I live in...

Re the data changing... is the USA looking to annex anytime soon?

Marc Gravell
Using states was just an example. It could be a list of widgets if that helps. I'll update the question. And yes, they are in the database.
Kon
I agree, if its possible to change the logic of the code to work on some key property that would probably be better.
KyleLanser
A: 

This cries out for a custom MSBuild task. You really want an autogenerated enum or class in this case; if the IDs are sourced from a database and can/will change, and are not easily predicted. You could then put the task in your project and it would run before each build updating as necessary.

Or start looking at ORMs :)

blowdart
Yep, autogenerating from DB seems to be the way to go. I was hoping there's some other mystical solution I was missing.
Kon
well you can make the build task nicely parameterised so it becomes mystical; and you can use it to generate multiple classes
blowdart
A: 

I believe that if it shows up in Intellisense, then, by definition, it is hard-coded into your program.

That said, if your goal is make the hard-coding as painless as possible, on thing you might try is auto-generating your enumeration based on what's in the database. That is, you can write a program that reads the database and creates a FOO.cs file containing your enumeration. Then just run that program every time the data changes.

Jeffrey L Whitledge
That's exactly what I'm currently doing - auto generating Lookup classes based on database table content. I was hoping to make it even less painful. :)
Kon