Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Best Design Patern for Multiple SQL Statements  RSS feed

 
Paul Duer
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hiya guys,
This is kinda a newbie question, but it's sure stumping me!
I have two methods that are exactly the same except the SQL statement which pulls data from two different tables, but with the same structure.
I want to write one base class that has all the other logic in it, and somehow references the correct sql statement.
I was considering subclasses that initalize the superclass on startup.
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Subclasses could work -- but maybe parameterization is better. Here's my question -- are you building the SAME value object in this DAO (Data Access Object -- see Core J2EE Patterns) or are you building 2 different Value object types? If it's the same, then just use a parameterized method to pick which table to use (e.g. have a single method called
MyValueObject buildFrom(String tableType)
or something to that effect.
Kyle
 
Paul Duer
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kyle,
I am binding the same value object. The only difference is the table name.
My concern was manageabilty. What I am actually doing is creating a new object and in the constructor, I run this data access routine, so the object has all the data in it from creation.
Then on a JSP page I use a Taglib to grab an iterator to parse through the rows into a combo.
So the combo is dynamic, if you select one page you get the combo with one set of data from one table, and if you select another then you get another.
I was afriad that putting a parameter on the constructor was bad form, but there is no way you can construct the object without selecting one or the other table.
I was just thinking it would be nice to have one master class and little subclassses with the table name as the parameter in the constructor.
Am I crazy?
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I wouldn't say parameterizing the constructor in this case was bad form at all! You should only make subclasses when instances behave differently -- what you've told me is that the value classes are absolutely identical except for the creation mechanism -- no other behavioral differences. This just screams out parameterized construction to me.
Kyle
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are almost sure the structure will not change in due course then I agree with Kyle. Parameterized constructor is a better solution than subclassing since the only thing that is different is the table name.
However, if you think the table structure might change in the future, then you can perhaps create two versions of the VO and DAO with a common abstract superVO and superDAO.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!