struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Lamb <>
Subject Re: Struts DB Access :: Best Practices
Date Thu, 10 Mar 2005 17:55:15 GMT
On 10 Mar 2005, at 07:59, Larry Meadors wrote:
> Disclosure: I am an iBATIS developer, so I'd like to offer another
> opinion on the comparison.


I might add an appendix to my documentation with this comparison. When 
I do, I'll give you another opportunity to complain. :)

>> - iBATIS does database pooling for you; Axamol does not. I prefer to 
>> use
>> the servlet container's built-in pooling.
> What about testing your DAOs? The dependency on the servlet container
> can become problematic.

The client code is expected to pass in a java.sql.Connection or 
javax.sql.DataSource, so there's no direct dependency.

>> - iBATIS does caching; Axamol does not. I haven't encountered the
>> situation in which I'd want quite the caching they have.
> I work with iBATIS on a project where I regularly do queries over
> multi-gigabyte tables. Caching is darn handy in those situations. :-)

I'm sure it is there. But I don't need it yet, and no one's complained 
to me that they do, either. I deliberately avoid writing features 
before they're needed.

>> - iBATIS has a lot of options to use JavaBeans, which I don't find
>> useful. I just take parameters in a java.util.Map and return a
>> java.sql.ResultSet directly. (I'm a DynaActionForm kind of guy, so 
>> using
>> a form bean form this would be a little out of place.)
> OK, now I have to just plain disagree with you. ;-)
> Using Maps and ResultSet in your application as the domain model is
> just plain bad design.
> It is difficult to test and too loosely coupled.

I used to be of this school of thought also. But, well, then I 
encountered Python. ;) I'd like to do things statically, but not at the 
expense of writing lots of code. I particularly hate code initially 
generated by tools that I have to manually maintain afterward.

And besides, everything else in a servlet container takes this approach 
- context, session, request, and page scope variables are all 
essentially map entries.

>> - Axamol includes XSLT and standardized elements for embedding
>> documentation in your libraries and producing HTML for them.
> Cool! I have wondered if including that in iBATIS would be used. Do
> your users use that much?

What users? ;) Axamol SQL Library doesn't have the community iBATIS 
does. I use it, a friend uses it, and I've gotten a fair number of 
downloads. But my projects can be weird that way...even with 
NetGrowler, which _must_ be popular (lots of downloads, I see 
occasional mentions of it on forums), I only hear from users when 
they've got a problem or feature request. So I don't know how many 
users I have, much less exactly what parts of it they use.

But my friend and I find it useful.

> A few other things I did not see in Axamol:
>  - row handlers

I'm not sure what you mean by this:

- The things for grabbing a a single int value and such when you do 
count(*), rather than dealing with the whole ResultSet? I've thought 
about adding those, but for now Axamol SQL Library is dirt-simple: it 
just always gives you the ResultSet.

- The things for linking to other queries on a per-row basis? I try to 
avoid those; I like my pages to make a constant number of queries.

>  - consistent dynamic sql (from what I see, there are different ways
> for altering the order and the where clauses..are there others?)

There's also the <s:bindlist/>, which is similar to your iterator.

> The binding looks more awkward to me:
>   iBATIS - select * from someTable where key = #id#
>   axamol - select * from someTable where key = <s:bind param="id"/>

It is. I did it this way initially to avoid having to do any parsing; 
just for ease of implementation. I might end up introducing a syntax 
like that.

> I like how you handle multiple databases. Simple. Good job on that.


> Cool project Scott, I hope you are not offended if we take some of
> your ideas for iBATIS. ;-)

I'd be flattered.

> Larry


Scott Lamb <>

View raw message