This reminds me of another question I've been meaning to ask.
Once upon a time, in a discussion of Business Logic Beanies, I
mentioned a "QueryFormBean", which is basically a poor man's uncached
RowSet. This is mean to encapsulate the JDBC red-tape, along with the
SQL command, the latter being read from a resource.
Craig then said:
> If you do it this way, do you need more than one QueryBean? Couldn't
you create a generic one that processes different kinds of query
strings based on the name of the resource you told it to read?
What would be the best approach for exposing one QueryBean (or RowSet)
to a Struts application? Set it up as another servlet, subclass the
Struts controller and set it up like an Action, or some other way?
Right now, to get started, I just put QueryBeans on the ActionForm as
member variables (as in the latest Fruit Glaze example).
There is a base object that provide the core fuctionality. I then have
a "fetch" method that is subclassed to transfer the resultset data
into an entity bean (or array of entity beans) that the form can use,
and a setParameters method that can be subclassed for prepared
statements.
I could easily put 80% or 90% of the QueryBean into a shared object,
but might still want a custom object for fetching entity data and
setting parameters. (Though, now that I say it, perhaps something
clever could be done with reflection.)
Anyway, I'm still not well versed on how Java works under the hood.
Would sharing one "big" object, but still creating the same number of
objects overall make an actual difference?
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
