I'm going to be totally honest.... If Java was Groovy, I never would have written iBATIS. The database APIs (especially the integration with GString -- despite a few limitations) is the smartest thing I've ever seen in database API design. Not only is it better than JDBC, it's better than Ruby's database APIs (not saying much). That combined with Groovy's support for multiline strings make it about 75% capable of doing what iBATIS does anyway. iBATIS was really a framework originally designed to solve only two problems:
* JDBC API verbosity * SQL looks like crap embedded in Java code (due to the lack of multiline strings and a decent string library) Groovy solves both of those quite well (perhaps iBATIS still has an edge). Later on we added... * Improved patterns for transaction management * A few bells and whilstles like caching, lazy loading, join mapping, etc... So that said, I suppose iBATIS could offer improvements in the area of transactions and the bells and whistles. But where would you see most of the value of a gBATIS (or whatever we'd call it)? :-) Cheers, Clinton On Tue, Apr 1, 2008 at 9:46 AM, tomasz brymora <[EMAIL PROTECTED]> wrote: > Greetings! > I just have a couple of quickie questions. > > Is anyone using iBatis with Grails? > > Are there any plans in the works for an iBatis plugin > for Grails? > > I've been working on project using Grails and as much > as I like the concept, it's integration with Hibernate > is pretty much a deal breaker for non-prototype dev. > > thanks, T >
