Depending between primary key in database and switch case statement

[asadikhan]

Hello,

I have a bit of a design issue around this application I am
developing, and I just want to run it through some of the brains out
here.

So I have a table called ErrorCheck which contains fields ErrorID (PK)
and ErrorName. There is another table called Client which contains
fields ClientID (PK) and ClientName. Then there is a relationship
table called ClientErrorCheck which contains foreign keys ErrorID and
ClientID.

The ErrorCheck table contains names and ids of checks that need to be
performed for clients.

In my code, based on the client that the user selects in a listbox, I
grab all the corresponding errors for that client and display in a
listbox (view only). The user then clicks a button which needs to
perform all those checks for the client.

The method that gets called when the user clicks that button has a
switch case statement which uses ErrorID to identify which method
needs to be called. Each ErrorCheck has a unique method containing the
logic for performing that check.

The problem is this: Even though the ErrorID is a primary key, shall
anyone ever change the ErrorID of a certain error in the ErrorCheck
table, my switch case statement may break or start pointing to the
wrong check methods. Even though the likelihood of this happening in
production is slim to none, I don't like this method because I am hard-
coding the ErrorIDs and their corresponding methods in my code, thus
causing a direct dependency between my application and the database.

So how can I solve this problem. Any ideas?

Regards,

Asad

 

[Daniel Pitts]

Hello,

I have a bit of a design issue around this application I am
developing, and I just want to run it through some of the brains out
here.

So I have a table called ErrorCheck which contains fields ErrorID (PK)
and ErrorName. There is another table called Client which contains
fields ClientID (PK) and ClientName. Then there is a relationship
table called ClientErrorCheck which contains foreign keys ErrorID and
ClientID.

The ErrorCheck table contains names and ids of checks that need to be
performed for clients.

In my code, based on the client that the user selects in a listbox, I
grab all the corresponding errors for that client and display in a
listbox (view only). The user then clicks a button which needs to
perform all those checks for the client.

The method that gets called when the user clicks that button has a
switch case statement which uses ErrorID to identify which method
needs to be called. Each ErrorCheck has a unique method containing the
logic for performing that check.

The problem is this: Even though the ErrorID is a primary key, shall
anyone ever change the ErrorID of a certain error in the ErrorCheck
table, my switch case statement may break or start pointing to the
wrong check methods. Even though the likelihood of this happening in
production is slim to none, I don't like this method because I am hard-
coding the ErrorIDs and their corresponding methods in my code, thus
causing a direct dependency between my application and the database.

So how can I solve this problem. Any ideas?

Regards,

Asad

Consider this, can you write your application to NOT be dependent on
the database in any way?

The answer is probably not.
If you add or edit an ErrorID, there has to be an update to the code
that handles it. Thats all there is to it.

Unless you want to put .class files in the database as a BLOB, and
assume that the class defined in the database implements an interface
(say) "ChecksErrors" which does what you want. And then you can
change the functionality of your program by adding a new class to the
database. By the way, this is a joke

There are a few workable alternatives, but it is the simplest (and by
extension, the best) to use the approach you've stated. At the very
least, if you have more than one switch statement that keys off that
value, you might consider using polymorphism instead. I.E. create a
ChecksErrors interface and an implementation of that interface for
every ErrorID. Then have a lookup table (probobably Map<Integer,
ChecksErrors> or ChecksErrors[], depending on the range of ErrorID).

Hope this helps.
Daniel.

P.S. Hard coding behavior is NOT a bad thing. You're programs behavior
is to do something different depending on the ErrorID, so having a
"hard coded" switch in this case is not a Bad Thing.

 

[Lew]

Daniel Pitts wrote:
you might consider using polymorphism instead. I.E. create a

ChecksErrors interface and an implementation of that interface for
every ErrorID. Then have a lookup table (probobably Map<Integer,
ChecksErrors> or ChecksErrors[], depending on the range of ErrorID).

Hope this helps.
Daniel.

P.S. Hard coding behavior is NOT a bad thing. You're programs behavior
is to do something different depending on the ErrorID, so having a
"hard coded" switch in this case is not a Bad Thing.

The polymorphic handler idea is very powerful, and it's how frameworks like
Struts and JSF work, for example. The lookup table can be instantiated from a
resource like a property file at program initialization.

When confronted with a switch off of an (essentially) enum value set,
polymorphism is usually the better choice. Plug in the handler that would've
been the method reached from the switch, but is now a class implementing a
common handle() (or do(), execute(), whatever()) method that knows how to
handle its use case.

The Map can be Map< ErrorID, Class<? extends ChecksErrors>>, that way you can
instantiate a new handler for each invocation instead of worrying about
re-using the same handler object each time.

 

[Daniel Pitts]

Daniel Pitts wrote:

you might consider using polymorphism instead. I.E. create a

ChecksErrors interface and an implementation of that interface for
every ErrorID. Then have a lookup table (probobably Map<Integer,
ChecksErrors> or ChecksErrors[], depending on the range of ErrorID).

Hope this helps.
Daniel.

P.S. Hard coding behavior is NOT a bad thing. You're programs behavior
is to do something different depending on the ErrorID, so having a
"hard coded" switch in this case is not a Bad Thing.

The polymorphic handler idea is very powerful, and it's how frameworks like
Struts and JSF work, for example. The lookup table can be instantiated from a
resource like a property file at program initialization.

When confronted with a switch off of an (essentially) enum value set,
polymorphism is usually the better choice. Plug in the handler that would've
been the method reached from the switch, but is now a class implementing a
common handle() (or do(), execute(), whatever()) method that knows how to
handle its use case.

The Map can be Map< ErrorID, Class<? extends ChecksErrors>>, that way you can
instantiate a new handler for each invocation instead of worrying about
re-using the same handler object each time.

You could also avoid reflection altogether and use a framework like
Spring to give you dependency injection. That way you're
relationships are in a "config" file.

 

[Roedy Green]

So how can I solve this problem. Any ideas?

This is a common problem.
see http://mindprod.com/jgloss/enum.html#DATABASES

This is a new entry I wrote specially for you. I am having trouble
logging in to FTP to upload it, so it won't be there right away.