commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@centras.lt>
Subject Re: [DbUtils]Making the BeanHandler... Even Smarter
Date Tue, 02 Dec 2003 06:13:28 GMT

----- Original Message -----
From: "David Graham" <grahamdavid1980@yahoo.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Tuesday, December 02, 2003 5:46 AM
Subject: Re: [DbUtils]Making the BeanHandler... Even Smarter


>
> --- Corby Page <CPage1@duke-energy.com> wrote:
> > Hmmm... I'm curious what the use case contexts are that people are using
> > DbUtils in. I'll give you mine:
> >
> > I am working in an enterprise development environment where application
> > developers are far removed from the DBA's that maintain the legacy
> > databases. The database and table structures of these databases are more
> > complicated than what can be handled with O-R mapping tools like
> > Hibernate
> > or CMP. So, I like using DbUtils in places where I need finer-grained
> > control over persistence mapping than what I can get from existing O-R
> > tools.
> >
> > In my environment, it is untenable to assume that database columns are
> > always going to exactly match the datatype and name of their associated
> > JavaBean properties. So, offering some ability to customize this would
> > be
> > an appealing feature of the library for me.
> >
> > David and Juazos both suggested that I place the select cause in a
> > property
> > or string to be shared by DAO's finders. But that relies on the
> > simplistic
> > assumption that every single select method will want to retrieve all of
> > the
> > columns from the table. My DAO's frequently retrieve subsets of the
> > columns
> > that will actually be used by the query, reducing critical serialization
> > overhead by as much as 75%. I suppose the alternative would be to define
> > a
> > separate named select string for each column set that is retrieved by a
> > finder, but that puts me right back where I started.
> >
> > David writes: "IMO, this feature is creeping towards framework status."
> >
> > Fine, then let's not implement the feature. But let's at least make the
> > library flexible enough so that people who want the feature can
> > implement
> > it. Hiding mapColumnsToProperties() as a private method of
> > BasicRowProcessor makes no sense, and it basically forces me to rewrite
> > BasicRowProcessor, rather than extending it, if I want to change the
> > behavior. In turn, this will make migration to later versions of DbUtils
> > more painful for me.
>
> The mapColumnsToProperties() method *does* make sense as a private method.
>  The member scopes in DbUtils were chosen deliberately, not randomly.
> They are private to avoid exposing implementation details to subclasses
> which make it harder to change the implementation later.  The whole point
> of defining a RowProcessor interface was to allow people to implement
> whatever special features they needed without having to customize our
> simple default
> BasicRowProcessor implementation.
>
> I'm not entirely opposed to making mapColumnsToProperties() protected but
> I strongly disagree with making other methods like newInstance()
> protected.  DbUtils isn't in the business of providing general Java helper
> methods related to non-database topics like reflection.  If there's a need
> for a newInstance() type of method it belongs in a different commons
> component.

It was not about reflection utility, factory method lets to decorate object
( dynamic proxy) or to generate bean on the fly, but  use cases are exotic
and are not very useful.

>
> Would changing mapColumnsToProperties() to protected allow you to fully
> implement your request?  Is representing the mapping as an int[] the best
> way of doing things?  Is there a better name for the method?
>
> David
>
> >
> > David writes: "Using an SQL 'AS' is simpler and clearer than writing
> > Java
> > code which forces you to maintain information about your queries in two
> > separate places, needlessly complicating things."
> >
> > I am using DbUtils in a large enterprise application, and the reason I
> > brought this up is because it is getting to the point where it is not
> > simpler or clearer. I think it makes sense to give users the option of
> > which approach they would like to take.
> >
> > Anyway, I wanted to make my points and I'm happy to offer up patches to
> > implement any of these suggestions. Thanks again to the authors of a
> > very
> > useful framework... err, library.  :)
> >
> > Corby
>
>
>
> __________________________________
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message