----- Original Message ----- From: "David Graham" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, December 02, 2003 5:46 AM Subject: Re: [DbUtils]Making the BeanHandler... Even Smarter
> > --- Corby Page <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
