By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,928 Members | 1,810 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,928 IT Pros & Developers. It's quick & easy.

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

P: n/a
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

Jul 13 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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.com

<as*******@gmail.comwrote in message
news:11**********************@22g2000hsm.googlegro ups.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 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

Jul 13 '07 #2

P: n/a
On Jul 13, 11:39 am, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.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]
- m...@spam.guard.caspershouse.com

<asadik...@gmail.comwrote in message

news:11**********************@22g2000hsm.googlegro ups.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 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
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.

Jul 13 '07 #3

P: n/a
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, ErrorHandlerType (or
something like that):

Id Error Other Field ErrorHandlerType
-- ----- ----------- ----------------
1 ERR1 Some Info MyCompany.ProductNamespace.Error1Handler
2 ERR2 Other Info MyCompany.ProductNamespace.Error2Handler

Then defining an interface like this:

public interface IErrorHandler
{
void HandleError();
}

You then define classes which look like this:

namespace MyCompany.ProductNamespace
{
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 ErrorHandlerType 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.com

<as*******@gmail.comwrote in message
news:11**********************@r34g2000hsd.googlegr oups.com...
On Jul 13, 11:39 am, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.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]
- m...@spam.guard.caspershouse.com

<asadik...@gmail.comwrote in message

news:11**********************@22g2000hsm.googlegr oups.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 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

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.

Jul 13 '07 #4

P: n/a
>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
Jul 13 '07 #5

P: n/a
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
Jul 13 '07 #6

P: n/a
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

Jul 13 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.