Reputation: 18639
If I have, say, a table of films which amongs other things has a int FilmTypeId field and a table of film types, with the id and a meaningful description along the lines of:
Whats the best way of using that information in a C# class?
currently I would have them as Constants in a helper class (unsuprisingly air code):
public class FilmHelper
{
public const int HorrorFilmType = 1;
public const int ComedyFilmType = 2;
...
}
but this doesn't seem that maintainable. But I would like to avoid a database call everytime I came to use the constant or an additional db call everytime I used either the helper or the main entity.
Upvotes: 6
Views: 2673
Reputation: 9812
If you want to use the property name the database rather than the ID, then I find it easier to use a static class with string constants inside. That saves lots of calls to Enum.Parse();
public static class SettingName
{
public const string PrimaryImageId = "PrimaryImageId";
public const string PrimaryImagePosition = "PrimaryImagePosition";
}
Upvotes: 0
Reputation: 50215
My answer assumes you want to explicitly code against those values in your database.
What I've done in the past is to build a script that creates my constants files. (I also had a SQL script that would output C# code when run with a text output so I could just paste it into the file and use that constant right away.)
If you do this, you can make it part of your continuous integration build and just get latest on that file when a build is done.
One thing to be aware of here is that when you delete rows from that table, some code may become unreachable/dead and, depending on how you implement your script, builds will break (this is a good thing to force you to remove the dead code).
Upvotes: 2
Reputation: 23315
Regarding using the enums... depending on what the enum value represents (e.g. an IDENTITY column), I might add a StaticIdentifier column to my table, and make THAT field the enum value for the lookup (modifying my stored procs appropriately to take the static identifier field instead of the identity column). Identity columns inevitably get messed up between DEV, QA, and PROD, and I don't need that hassle.
Upvotes: 1
Reputation: 43168
You can use a strong type without strongly-typing the values.
class FilmType : Dictionary<int, string> {}
Then just load the values at app load time, as Joel suggested.
If you're more concerned about the actual values at compile-time, then you're not going to do better than an enum.
Upvotes: 4
Reputation: 415735
I'd actually pull it from the database when the app starts, or join on the table in any queries where the data is used.
Upvotes: 1
Reputation: 33098
I always store my code look ups inside Enumeration files similar to this
public enum ReportStatus
{
[Description("Reports that are running")] Running,
[Description("Reports that are pending to run")] Pending,
[Description("Reports that have errored while running")] Error,
[Description("Report completed successfully.")] Finished
}
To read from the Description tags of the enum I use a class simliar to this example from Monsters Got My .NET. This leaves you with the flexibility to store the ID, Code and Description of a look up type object in an enum at the same time.
Upvotes: 1
Reputation: 1062770
Is the list of types fixed or does it change?
If fixed, I would encapsulate it in an enum:
public enum FilmType {
Horror = 1,
Comedy = 2
}
Then just cast. You can use attributes (and a few lines of bespoke code) to store an extra description per enum item.
If the list changes I would probably read it once early on in the app, and cache the list in a lookup somewhere (perhaps static, perhaps in a specific cache). Then just do the lookups from the cached copy.
You can take this further by adding properties that change between the two representations.
Upvotes: 6