Apologies in advance, this is likely going to be a long-winded message. ;)
To give everyone a perspective from the "other side of the tracks", I am a relatively new user of iBATIS, but I previously had well over a year of solid Hibernate experience in production (with another year of 'tinkering' with Hibernate before that, dating back to Hibernate 1.2). I've also used Apache's Object Relational Bridge (OJB) in production, and have 'toyed' with JDO, Apache Torque, Cayenne, Castor and even pBeans. ;) Of course, I've done a *lot* of JDBC and some EJB entity beans (but very little -- not a big fan of these ;) While I've only been using iBATIS for about 3 months, I'd say the situation for using iBATIS over Hibernate is much as Paul described, but I'd like to possibly stress that it might be even more polarized than he indicated. As a part of the architecture team on my last project, we had the 'luxury' of dictating the data model as well as the choice of object-relational mapping tools. A previous iteration of the software we were "refactoring" had tried a custom JDBC framework that was very difficult to maintain, and scalability was always in question. We decided to accept an industry standard "universal data model" and tried to make Hibernate "fit" with it, instead of letting Hibernate "push" the objects into a relational data model (which is the easiest way to use Hibernate). For those of you not familiar with Hibernate, I would not recommend trying to force Hibernate to work with a data model. There are certain Hibernate guidelines that you must fit within (from a relational perspective) in order to not encounter issues. All in all, though, once you "tweaked and tuned" Hibernate and the relational model to compensate, it turned out to be very nice to work with. The mapping was all done within the Java classes, using XDoclet and generated mappings with an Ant task. Afterwards, querying for objects already mapped was a very, very trivial task -- and inserts, updates and deletes were equally simple, especially with large object hierachies. Being able to say ".save(GreatGrandParentObject)" and have it save all GrandParents, all Parents and all Children automatically (or updates or deletes without worry what needed to be done where) was quite nice. On to my current project we use iBATIS, since a large portion of the SQL had been or is created by several developers with years of experience in SQL against an "off the shelf" ERP data model (i.e. very little control over). In this case, iBATIS is lightning fast to use: copy the SQL statement directly from your favorite SQL query tool, past into the SqlMap XML file, and write your mapping ResultMap, and viola, you're up and running. Unfortuantely, I've not had much experience with the "push" part of iBATIS (updates, inserts, delets), so it's difficult to speak here, but I would expect the same 'ease of use'. I recently made the statement to a co-worker that I'll probably never use straight JDBC again because of iBATIS. Finally, regarding performance turning: I'd say that this depends on your experience with each product, and SQL in general. There are a number of "tricks" in Hibernate (with lazy loading, proxies and caching) that can be used to "tune" a particular situation. The same would apply to iBATIS, as long as you were pretty good with SQL and DB design (indexes, eliminating LIKEs and other things that might force full table scans, etc.). So in summary, Hibernate is great when you control the data model, and you let Hibernate do most of the work in the persisting of objects. Trying to add Hibernate to an existing data model is possible, just usually not trivial (unless your models trivial). On the flip side, it's least likely to please a DBA since the relational scheme could look 'odd' in situations, and the SQL is more difficult to tune. But once it's setup and tuned, you'd begin to see your biggest productivity gains. On the other hand, it feels as if iBATIS can adapt to any situation, but of course this is (in my opinion) highly dependent on the SQL skills and experience within your organization. It's just as easy to write a 10 table JOIN with 3 sub SELECTS and 5 LIKE clauses against a few million records to see problems. ;) Likewise, if you have a good DBA or good SQL developers, this situation is MUCH, much easier to tune. I hope someone finds this information helpful. On Sat, 26 Feb 2005 22:47:30 -0700, Larry Meadors <[EMAIL PROTECTED]> wrote: > 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 > <[EMAIL PROTECTED]> wrote: > > Well said Paul. > > > > Clinton > > > > > > On Sat, 26 Feb 2005 21:20:19 -0500, Paul Barry <[EMAIL PROTECTED]> 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? > > > > > >
