 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / July 2007Depending between primary key in database and switch case statement
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 On Jul 13, 8:31 am, asadik...@gmail.com wrote: > Hello, > [quoted text clipped - 34 lines] > > 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. 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, [quoted text clipped - 6 lines] > 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.  SignatureLew > you might consider using polymorphism instead. I.E. create a > [quoted text clipped - 25 lines] > -- > Lew 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. >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. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.