Hello, I've been using iBATIS as the db interface for APIs that are used by many different kinds of clients for almost two years now.
When I get a request for a new piece of functionality, I first try to implement it using only Java and the Abator generated classes. A good chunk of the "no brainer" work can be handled this way without writing any new SQL or touching the XML. If the functionality does require new SQL, I generally try to make the SQL return something that can be used by an Abator generated result map or a simple grouping result map using the Abator generated classes. For queries with results that don't map well to the Abator classes, a good chunk end up being scalar values (string or int) or to lesser degree a Map. If that doesn't work then I'll go to a RowHandler with a Map result class. These RowHandler queries make up a small percentage of my iBATIS SQL but generally are the most complicated and performance aware SQL I have. I should probably write more complicated result maps in the sql map XML, but I find it much easier to handle a Map in Java than group things together in XML. I guess what I'm saying is that if your data model is static, your model objects will be static too and you can reuse them in different sql maps. My experience with Hibernate is that it's fast and easy to get going out of the box and much more OO friendly, but you spend all your time reverse engineering Hibernate to figure out what its doing when against the RDBMS. If you don't have high performance SQL requirements and you have a small dataset, then Hibernate might be all you need. For me, iBATIS takes a little more up front time because you don't automatically get joins or CRUD (although Abator goes a long way with the CRUD handling). But you have complete control over what gets run when, which makes all the difference for me. I recently wrote an app in a few weeks that had to deal with 30M+ row tables and knowing exactly what is running when is required for that kind of thing. But then, in the impedance mismatch war, I'm OK with favoring the relational model because I know how to make it scale and I know it'll be around in 10 years when we're all writing Ruby clients;) Cheers, Chris -----Original Message----- From: vinays84 [mailto:[EMAIL PROTECTED] Sent: Sun 6/17/2007 3:15 PM To: [email protected] Subject: RE: New to iBatis Thanks for all the replies. I'd like to quickly compare using iBatis vs. Hibernate. I'm not an expert on either, so please correct any false assumptions I make: With Hibernate, the entire data model is mapped out for the application, which can initially take a while and have a lot of configuration, but once complete, will allow the developer to access the update the data model as the application develops with any specific queries that they see fit, without adding any extra POJOS or configuration code. iBatis, on the other hand, is much simpler to set up, but configuration and java code (POJOS and DAOS) will have to be added as more queries are added to the application because each result class will have to be specifically designed for the individual query. Please edit/add anything that you think so I may get a proper understanding of the differences between the two frameworks. Thanks! -- View this message in context: http://www.nabble.com/New-to-iBatis-tf3922862.html#a11167014 Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
