4

I have a database table that essentially contains different types of things. I'll use animals as an example. I have a table called AnimalTypes:

AnimalTypes
{
     ID:int,
     Name:string
}

I then populate it with:

1:Dog,
2:Cat,
3:Fish

I would like to then have some sort of C# object created that functions similar to this enum be entirely read from the database:

enum AnimalTypes
{
     Dog = 1,
     Cat = 2,
     Fish = 3
}

Is there a way to create an enum/class from a database table as described? I basically want to be able to reference things in the AnimalTypes table using intellisense and AnimalTypes.Dog as an example; I don't actually need an enum, just something that kind of functions like one. Is this possible?

Edit: I'm not really that thrilled about generating a DLL as I've seen in other related problems. I feel like this should be possible with reflection.

Lets suppose I don't need intellisense.

Mark
  • 85
  • 1
  • 2
  • 5
  • Reflection and Intellisense don't often go hand-in-hand. – Anthony Pegram Dec 22 '10 at 04:52
  • @Anthony: Perhaps some trick with anonymous types then? Do you at least understand what I'm trying to do? I just don't want to maintain two lists; one in C# and the other in a DB. – Mark Dec 22 '10 at 04:54
  • Does this answer your question? [Automatically create an Enum based on values in a database lookup table?](https://stackoverflow.com/questions/725043/automatically-create-an-enum-based-on-values-in-a-database-lookup-table) – StayOnTarget Mar 31 '20 at 11:58

3 Answers3

3

Try this solution:

using T4 code generation for lookup tables.

Kijewski
  • 25,517
  • 12
  • 101
  • 143
Ronen Rabinovitz
  • 81
  • 1
  • 8
3

You will have to generate an assembly if you want to be able to use the enumeration or class at compilation time. Reflection happens at execution time so that won't give you intellisense.

This is a common problem - there are a set of distinct values in a database table and those values don't change often so they are modeled as an enum in the source code. This allows these somewhat static values to be easily used in a very readable way. The problem is that when the values do change, it would be nice if the enum changed as well.

The problem with trying to keep the enum and database in sync is that an automatic process doesn't change the fact that if you are changing the database it would be very unlikely that you would do so without having to roll new code to leverage the changed value. It is better to model these values as an enum and still store them in the database. Just manually sync them as the need arises.

Andrew Hare
  • 344,730
  • 71
  • 640
  • 635
  • Is there a better way to solve the problem of maintaining two lists, one in C# and the other in a DB? – Mark Dec 22 '10 at 04:56
  • I don't understand the reason to have two lists to begin with, either have it in the DB or C#. – Phill Dec 22 '10 at 05:01
  • 1
    That's not really the answer I *wanted* to hear, but its an answer none the less. I'm gonna leave my question open in case anybody else has any other answer. I'll mark yours correct if there are no better solutions by tomorrow. – Mark Dec 22 '10 at 05:03
  • @Phil: I need to have an enum in C# and then a table in the DB that contains the exact contents of the enum. I basically have entities (Animals) that have a type. Depending on the type that is stored in the db, I do something differently in code. Like `if (Animal.AnimalType == AnimalType.Fish) {//drawFish()}` Here Animal.AnimalType is in the DB and AnimalType.Fish is an enum. – Mark Dec 22 '10 at 05:06
  • OK, so based on the enum/db you cater for every scenario. Now assume we add an Elephant, you can't cater for an elephant until you've written the code, so modifying the DB or Enum is pointless until that scenario is handled correct? So you could still in theory, store the types in Either the Database, or the Enum, and not have it stored in two places... – Phill Dec 22 '10 at 05:21
  • we tend to store as enum and database, simply because displaying the data to the user, for instance in a report (which probably wont use our library) is far easier straight from the DB, and we dont like 'magic' numbers in our code, its not ideal but it really isnt that bad. – Richard Friend Dec 22 '10 at 09:29
  • 1
    I have seen both used - the database values are useful as foreign keys and the enum is useful to make the application code more readable. – Andrew Hare Dec 22 '10 at 12:29
0

There's always code generation: http://www.mygenerationsoftware.com/ if you don't want to go the reflection route.

Matt H
  • 7,311
  • 5
  • 45
  • 54