On Wed, 09 Mar 2005 15:48:52 -0600, Scott Lamb <[EMAIL PROTECTED]> wrote: > karthikeyan balasubramanian wrote: > > I looked at iBATIS, it seems to be simple and easy to use. I will > > also check out > > others and let you know my thoughts. > > I'll add one to your list: Axamol SQL Library > <http://www.slamb.org/projects/axamol/sql-library/> > > It's a project of mine, so I'd love to hear if it works out for you. (Or > if it doesn't do what you need, but could if I added feature X.) > > It is similar to iBATIS SQL Maps but lighter / narrower in scope. I > looked over their user manual recently, and the differences I spotted were:
Disclosure: I am an iBATIS developer, so I'd like to offer another opinion on the comparison. :-) > > - 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. > > - 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. :-) > > - 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 am sure Vic will disagree with me if he's reading this. :-P > > - iBATIS has a lot of support for translating "magic" values (of the > 9/9/99 variety) into nulls, which is a fundamentally bad idea. Axamol > doesn't do this and never will. Hmm, I tend to agree that this is a bad idea. I avoid that, too. > > - iBATIS's conditional SQL elements have this prepend="..." attribute > that I find confusing. I accomplish the same thing just by using boolean > identities: "true and boolvar" = "false or boolvar" = "boolvar". Compare > the example on iBATIS SQL Map's developer guide page 35 to my example > two at > <http://www.slamb.org/projects/axamol/sql-library/manual/pr01s02.html> > and you'll see what I'm getting at. That is an interesting approach. Very simple. I have yet to see a clean way of dealing with this problem. IMO, no SQL framework feels quite right for this stuff. When I was coding SQL directly in Java, I did it the way you describe. > > - 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? > > - Axamol captures timing statistics which are useful for determining > where you need to optimize your SQL. That is a nice feature, and I think it would be easy to add to iBATIS...maybe in the next version. A few other things I did not see in Axamol: - row handlers - consistent dynamic sql (from what I see, there are different ways for altering the order and the where clauses..are there others?) The binding looks more awkward to me: iBATIS - select * from someTable where key = #id# axamol - select * from someTable where key = <s:bind param="id"/> With many parameters, this would get really noisy IMO. 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. ;-) Larry --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
