On a related note: I am in the process of refactoring an application
where I work that used Hibernate. One of the screens that was timing
out after over 10 minutes is now coming up in under one minute.
In my experience, the performance of Hibernate (especially when
dealing with large datasets) is VERY overrated.
That said, if you will be working with large data sets, and
performance is a criteria, my suggestion would be iBATIS.
Larry
On Sat, 26 Feb 2005 20:21:38 -0700, Clinton Begin
<clinton.begin@xxxxxxxxx> wrote:
> Well said Paul.
>
> Clinton
>
>
> On Sat, 26 Feb 2005 21:20:19 -0500, Paul Barry <paul.barry@xxxxxxx> wrote:
> > I don't know of a site with a detailed comparision, and if you find one,
> > let me know. But I can tell you this difference boils down to this;
> > iBATIS maps Java Objects to the results of SQL Queries, whereas
> > Hibernate maps Java Objects directly to database tables, traditional
> > Object-Relational Mapping. The benefits of Hibernate are that it
> > automatically generates all the SQL for your and the cache invalidation
> > can be more fine grained. iBATIS is more flexible especially if you are
> > a strong SQL query writer. You have control over exactly how the SQL
> > queries are written.
> >
> > When determining which framework to use, I think one thing to remember
> > is that there is an optimal relational model to support every object
> > model. There is not an optimal object model to represent every
> > relational model. Use hibernate if you have mostly standard
> > queries(CRUD, Find by Criteria, etc.) and if you are designing your
> > object model first, then a relational model to support the object model.
> > If you are working with a legacy system or a schema designed by a DBA,
> > iBATIS often makes a better choice. If you try to shoehorn hibernate
> > into a relational model created by a DBA who could care less about
> > objects and thinks in terms of tables, columns, relationships and record
> > sets, then you will get along better with your DBA if you use iBATIS,
> > especially if the model is complex and may entail queries with outer
> > joins and nested subqueries. You can tell them "All of the SQL
> > statements used by my application are stored in these XML files outside
> > of my Java code, so you can easily review them". DBAs like that. Of
> > course, you might be lucky enough to work with a DBA that is familar
> > with OO design and ORM tools like hibernate, in which case hibernate
> > might make a better choice.
> >
> > Bottom line, in my experience, compared to Hibernate, iBATIS is more
> > flexible, has a shorter learning curve, but can take more time to
> > develop and maintain, since you have to write all your queries and if
> > your object model changes you have to go through all your queries and
> > make sure to make all the necessary changes to reflect the changes in
> > your object model. I must admint though that I am biased because I have
> > more experience with iBATIS. As I gain more experience with Hibernate,
> > I could be singing a different tune.
> >
> >
> > Tim Christopher wrote:
> > > Hi,
> > >
> > > Can anyone point me in the right direction of a site that compares
> > > iBATIS to similar products, ie. Hibernate.
> > >
> > > Cheers,
> > >
> > > Tim Christopher
> > >
> > > Ps. Is it possible to specifiy a flush interval in a unit other than
> > > hours? Also is there an upper limit for the time?
> >
>
|
