Re: [Springframework-developer] iBATIS Database Layer

[<tri...@tr...>]

Juergen,

I agree with most if not all of your points.  I definitely agree that getting
out a release and provide documentation should now be top priority, if we want
Spring to get a bigger following than it already has.

I have not used iBatis, but I did read up a little bit about it and I did like
some things.  Two things that iBatis has that we don't, is support for caching
and the query/mapping declarations in an XML descriptor instead of Java code. 
It would be nice if we could provide caching at some point.  

There is also a plug for "Axle" on the iBatis website.  This seems to be
Clinton's latest project.  Axle - JSP-Like Tags, Easy Custom Tag Handlers, Front
Controller, MVC, No Scriptlets! (http://www.ibatis.com/axle/axle.html).

The framework field is getting crowded.

--Thomas


> One more conclusion: We need to get out a proper release prompty, to be able
> to raise awareness. There are hardly any cleaner and slicker implementations
> out there for the problems that we address, so we really don't need to hide
> :-) Some competing solutions have quite nice docs though - we have to keep
> improving in that area.
>  
> BTW, the motivation behind my thoughts is to keep a clear third party
> strategy: i.e. address the "integrate vs compete" question on a case-by-case
> basis:
>  
> - For areas like logging, connection pooling, O/R mapping, distributed
> transactions, remoting, web views we've decided to adopt common solutions
> like Log4J, container DataSources, Hibernate/JDO, JTA,
> Hessian/Burlap/RMI/SOAP, JSP/JSTL/Velocity/etc.
>  
> - On the other hand, we rather compete with Struts and WebWork (although it's
> easy to use them instead of Spring's web MVC), and obviously with the iBATIS
> Database Layer too. The nice thing is that for some other areas our solutions
> are so unique that we don't have any actual competition :-)
>  
> Juergen
>  
>  
> 
> 	-----Ursprüngliche Nachricht----- 
> 	Von: jürgen höller [werk3AT] 
> 	Gesendet: Mo 09.06.2003 18:34 
> 	An: spr...@li... 
> 	Cc: 
> 	Betreff: [Springframework-developer] iBATIS Database Layer
> 	
> 	
> 
> 	Hi database access enthusiasts,
> 	
> 	Some of you might have followed some recent discussions on Clinton Begin's
> "iBATIS Database Layer" (http://www.ibatis.com/common/common.html), e.g. on
> TheServerSide and the Resin mailing list. I've just reviewed it, and I'd like
> to share my thoughts on it.
> 	
> 	iBATIS Database layer originated in Clinton's JPetStore implementation, he
> used it there in combination with Struts. It's now a separate open source
> distribution, repeatedly pushed e.g. by Vic Cekvenich as a database access
> solution for Struts web apps. Clinton himself labels it "A better way to
> write JDBC" - we know that goal, don't we? ;-)
> 	
> 	iBATIS is somewhere inbetween our jdbc.object package and a full O/R mapping
> tool. It maps symbolic names to SQL statements and parameter objects, using
> manually specified SQL alias names for matching columns to bean properties.
> Dependent objects can be loaded by delegating to a separate SQL statement. In
> terms of the functionality offert, this is quite similar our jdbc.object
> support, just declaring in XML instead of Java code.
> 	
> 	It lacks a lot compared to a full-fledged O/R mapper like Hibernate, e.g. an
> object query language, lazy loading with configurable outer joins, dirty
> detection and object transactions, cascading insert/update/delete, etc. It
> does have configurable cache support, though. But in total, there's no reason
> to provide a Spring integration for it like for Hibernate or JDO, as it isn't
> really about O/R mapping.
> 	
> 	One interesting thing is iBATIS' pluggable DAO support: a DaoManager that
> reads DAO configuration from an XML file, instantiating specified DAO
> implementations (e.g. for generic SQL or optimized for Oracle) that implement
> a Dao tag interface and throw generic DaoExceptions. There's even support for
> pluggable DataSource factories, and for a pluggable DaoTransaction that needs
> to get passed to every DAO method. Sounding familar again? ;-)
> 	
> 	Our DataAccessException hierarchy and abstract transaction management
> support address the same issues. Although IMHO in a more elegant way:
> leveraging the generic BeanFactory approach for instance configuration, using
> implicit thread-bound transactions that don't need to get passed to methods,
> providing a convenient template and an AOP interceptor for it. And we have
> implementations for JTA + transaction container DataSources, a single JDBC
> DataSource, a Hibernate SessionFactory, and a JDO PersistenceManagerFactory.
> 	
> 	One could say that Spring's relation to the iBATIS Database Layer is similar
> to its relation to WebWork or Struts: Spring offers similar functionality
> with differences in terms of modelling approach, but all of it integrated
> into one coherent approach for all application layers - while still being
> individually reusable.
> 	
> 	So it seems that we're on the right track: Some of the main design ideas
> that we've adopted keep emerging in bits and pieces of various other
> frameworks. Though in many cases for an isolated functionality domain, and
> often not drawn through as consequently.
> 	
> 	Any thoughts, experiences, suggestions on this?
> 	
> 	Regards,
> 	Juergen
> 
>