Hardcoding database primary key in switch statement / Design, Dependency issue

[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 ClientErrorChec k 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

[Nicholas Paldino [.NET/C# MVP]]

Is there any way that you can reflect the methodology associated with an
error in the database, and eliminate the problem all together?

For example, you have specific code based on the error id. What I would
do is abstract out the operation into an abstract class or interface, and
then have a field on the errors table which has the name of the type that
extends the abstract class or implements the interface. This way, if the
ids change, it doesn't matter to you, as your code would just get the
implementation of the algorithm from the error record itself.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

<as*******@gmai l.comwrote in message
news:11******** **************@ 22g2000hsm.goog legroups.com...

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 ClientErrorChec k 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

[asadikhan]

On Jul 13, 11:39 am, "Nicholas Paldino [.NET/C# MVP]"
<[e-mail] d.caspershouse. comwrote:

Is there any way that you can reflect the methodology associated with an
error in the database, and eliminate the problem all together?

For example, you have specific code based on the error id. What I would
do is abstract out the operation into an abstract class or interface, and
then have a field on the errors table which has the name of the type that
extends the abstract class or implements the interface. This way, if the
ids change, it doesn't matter to you, as your code would just get the
implementation of the algorithm from the error record itself.

--
- Nicholas Paldino [.NET/C# MVP]
- [e-mail] .caspershouse.c om

<asadik...@gmai l.comwrote in message

news:11******** **************@ 22g2000hsm.goog legroups.com...

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 ClientErrorChec k 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

Would you mind to elaborate on that a little. I read what you said a
few times, but I'm not clear on it. Can you give me some example code?
Nothing big, just makeup small classes with comments should do? Really
appreciate it.

Thanks.

[Nicholas Paldino [.NET/C# MVP]]

So you have this switch statement:

switch (id)
{
case 1:
// Do something
case 2:
// Do something else
}

Where id is the id in the database. The errors table looks like this:

Id Error Other Field
-- ----- -----------
1 ERR1 Some Info
2 ERR2 Other Info

What I am suggesting is creating another field, ErrorHandlerTyp e (or
something like that):

Id Error Other Field ErrorHandlerTyp e
-- ----- ----------- ----------------
1 ERR1 Some Info MyCompany.Produ ctNamespace.Err or1Handler
2 ERR2 Other Info MyCompany.Produ ctNamespace.Err or2Handler

Then defining an interface like this:

public interface IErrorHandler
{
void HandleError();
}

You then define classes which look like this:

namespace MyCompany.Produ ctNamespace
{
public class Error1Handler : IErrorHandler
{
public void HandleError()
{
// Do the error handling for error 1 here.
}
}

public class Error2Handler : IErrorHandler
{
public void HandleError()
{
// Do the error handling for error 2 here.
}
}
}

Then, in your code, instead of just getting the id from the database,
you would also get the ErrorHandlerTyp e from the database. Once you have
that string, you can create a Type instance from that, and pass it to the
static CreateInstance method on the Activator class. It will create a type.
You then cast that return value to the IErrorHandler interface, and call the
HandleError method.

Of course, your situation might require more properties/methods on the
interface, as you will have to initialize with other information, most
likely, but that's pretty much it.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

<as*******@gmai l.comwrote in message
news:11******** **************@ r34g2000hsd.goo glegroups.com.. .

On Jul 13, 11:39 am, "Nicholas Paldino [.NET/C# MVP]"
<[e-mail] d.caspershouse. comwrote:

> Is there any way that you can reflect the methodology associated with
an
error in the database, and eliminate the problem all together?

For example, you have specific code based on the error id. What I
would
do is abstract out the operation into an abstract class or interface, and
then have a field on the errors table which has the name of the type that
extends the abstract class or implements the interface. This way, if the
ids change, it doesn't matter to you, as your code would just get the
implementati on of the algorithm from the error record itself.

--
- Nicholas Paldino [.NET/C# MVP]
- [e-mail] .caspershouse.c om

<asadik...@gma il.comwrote in message

news:11******* *************** @22g2000hsm.goo glegroups.com.. .

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 ClientErrorChec k 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

Would you mind to elaborate on that a little. I read what you said a
few times, but I'm not clear on it. Can you give me some example code?
Nothing big, just makeup small classes with comments should do? Really
appreciate it.

Thanks.

[Samuel R. Neff]

>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.

Typically what I would suggest is adding a new field like ErrorRef
which is a C#-keyword appropriate name and would be considered
internal to your system (whereas ErrorName can change over time if
wording needs to be different and can have invalid characters,
ErrorRef would never change and would be a valid C# keyword).

Then create a enum in C# where the names are the ErrorRef values and
the values of the enum are the ID's. Ideally the enum can be
generated directly from the database and you would have a unit test or
even a runtime test to confirm that the values all match.

Then youc an program against the enum which is safer than using the ID
(especially if you have tests to confirm matching values in db and
code).

HTH,

Sam
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Fri, 13 Jul 2007 08:30:42 -0700, as*******@gmail .com wrote:

>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.

....

>
Regards,

Asad

[Mark Wilden]

I like Nicholas's idea. However, a simpler approach is the one we use, where
tables like ErrorCheck have a Moniker column with a check constraint and a
uniqueness constraint. We refer to rows via the moniker, not the ID.

///ark

[asadikhan]

Ok thanks guys. That's exactly the kind of ideas I was looking for.
Some of this stuff went right over my head, but now I'm gonna play
around with it until I understand. Thanks again.

Regards,

Asad