Disclosure: I am an iBATIS developer, so I'd like to offer another opinion on the comparison.
Cool!
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.
Thanks.
Cool project Scott, I hope you are not offended if we take some of your ideas for iBATIS. ;-)
I'd be flattered.
Larry
Regards, Scott
-- Scott Lamb <http://www.slamb.org/>
PGP.sig
Description: This is a digitally signed message part
