Magic codes, enums, or ...?

[Hans Kesting]

Hi,

In a database some code is stored as a string. This code can have a
limited (known) set of values. What is the best way to use this in my
(program-)code?

I don't want to use "magic codes" like
CustomerInterface.StoreLevel(CustomerID, "BEH");
because this would give no indication what sort of string was expected
and what the accepted values were.


I could declare a const:
public const string Level1 = "BEH";
and use it like
CustomerInterface.StoreLevel(CustomerID, CustomerInterface.Level1);

This way the magic code is somewhat under control, but still there
would be no way to prevent someone from using an unknown string like
"XYZ". The compiler would not complain, but a runtime error would
(probably) follow. There would be no way to guarantee that one of the
"CustomerInterface" conts is used.


Third option, use an enum:
public enum Levels { Low, Medium, ... };
CustomerInterface.StoreLevel(CustomerID, Levels.Level1);

This way the compiler would make sure I really use a "Levels" value
(OK, I could use '(Levels)6' but that would be cheating).
The downside is that somewhere I would have to translate from this
Levels enum to the string code because that database only accepts a
string, and that can't be changed. So I use a separate class:
class EnumConverter
{
public static string LevelToCode(Levels theLevel)
{
switch (theLevel)
{
case Levels.Low: return "BEH";
case Levels.Medium: return "EO";
...
}
}
}
But this seems to me more like Oh-Oh programming than the OO version.

Does anyone know a better way where I can specify the "level" in a
typesafe way and encapsulate the "ToCode" and "ParseFromCode" methods?

Thanks,

Hans Kesting

 

[Marc Gravell]

The downside is that somewhere I would have to translate from this Levels

enum to the string code because that database only accepts a string, and
that can't be changed.
{snip}
But this seems to me more like Oh-Oh programming than the OO version.

This still seems the right option to me; the natural place for a finite,
fixed list of
options in the
CLR is an enum; how the database stores it is the database's problem. When
transitioning between universes (OO <--> DB), there is always some level
of translation required; sometimes this can be with casting or
..Parse()/.ToString(),
and sometimes it can't. You just need to put this translation code alongside
this code that deals with the sp-name, or SQL command, or whatever (your
adapter, DAL, or where-ever else that code is living).

At the end of the day, your data entities are there to model the system; NOT
to model the database... the database exists purely for long-term storage.
So
let your OO-code use the best that the OO-world has to offer, and let your
SQL code do likewise with SQL.

Marc

 

[Hans Kesting]

The downside is that somewhere I would have to translate from this Levels

This still seems the right option to me; the natural place for a finite,
fixed list of
options in the
CLR is an enum; how the database stores it is the database's problem. When
transitioning between universes (OO <--> DB), there is always some level
of translation required; sometimes this can be with casting or
.Parse()/.ToString(),
and sometimes it can't. You just need to put this translation code alongside
this code that deals with the sp-name, or SQL command, or whatever (your
adapter, DAL, or where-ever else that code is living).

Marc

Still it would be nice if I could add the "ToCode()" method to the
enum. (C# 1.1)

Thanks for the reply,

Hans Kesting

 

[Marc Gravell]

In some ways yes, but it depends on how "pure" you are at modelling your
objects. Some people stick strictly to the "one class, one purpose"
paradigm; the job of your entities is to represent the data, not to talk to
a database. That is sometimes the role of a separate adapter / DAL
construct. With this view, the object shouldn't really even need to know
that there *is* a database - or indeed, the object could sit above 5
different database implementations with different schemas and
representations of the magic codes, with a different adapter for each. You'd
then need a parameter on the ToCode() method, and all of a sudden your
business objects are tightly coupled to the database again...

But I see your point; Jon Skeet has some interesting thoughts on other ways
to improve enums along Java lines; I suspect what you are talking about
would fit somewhere on this page...

http://msmvps.com/blogs/jon.skeet/archive/2006/01/05/classenum.aspx

Marc

 

[Kevin Spencer]

public enum stringEnum
{
foo = 0,
bar = 1
}

string s = stringEnum.foo.ToString(); // yields "foo"

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

Expect the unaccepted.

 

[Hans Kesting]

public enum stringEnum

{
foo = 0,
bar = 1
}

string s = stringEnum.foo.ToString(); // yields "foo"

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

Yes, but the code is *really* a "code", that is: short, not really
descriptive. I don't want a "ServiceLevel.EO", I want a
"ServiceLevel.ExecuteOnly" that translates to "EO".
(I know that it is possible to add IntelliSense comments so that the
description for EO is "Execute Only" but I don't like to *depend* on
that to make sense of my code)


Hans Kesting