I have not worked with iBATIS... and the intention was not to compare hibernate vs. iBATIS .... The recommendation I was making was to use Hibernate instead of raw JDBC calls embedded in your code.
And surely ... designing your database the "hibernate way" brings in some constraints which I think is OK if you are starting something fresh... and as Larry pointed out may or may not be worth a re-engineering effort. ~raghu On 11/28/05, Larry Meadors <[EMAIL PROTECTED]> wrote: > > Having used both iBATIS and Hibernate on large systems (100's of > tables, 100's of GB of data), I would recommend iBATIS, especially if > you are coming from a shop that has any good SQL experience. > > It does caching on both levels (connection pooling and POJO caching), > and makes managing queries and using stored procedures MUCH easier. > > Hibernate seems to be a decent approach if you have LOTS of memory, > and a new database that you can structure specifically for it. For a > legacy database that is expensive to change, it is worthless IMO. > > Saying that "you should use it unless you have a strong reason not to" > is an over-simplification. > > Larry > > On 11/28/05, Raghu Kanchustambham <[EMAIL PROTECTED]> wrote: > > These are two different caching scenarios we are talking about. > > Tomcat connection pooling caches "Connection" objects.. not your > > domain objects. However, Hibernate caches business objects > > (POJOs). You could use Tomcat's connection pool along with > > Hibernate's pooling of business objects. > > > > I do believe using Hibernate has tremendous advantages over not > > using it ... specially in mid-to-high complex projects - specially > > from a maintenance and extendability point of view. Performance > > wise I dont think there is a huge difference... unless you use > > JDBC and write custom caching (very very specific to your > > needs as Hibernate provides decent level of caching). > > > > Hibernate has very good documentation too and is quite mature. > > So you should use it unless you have a strong reason not to ! :-) > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
