You are correct: iBatis is not an ORM tool, but instead simply a tool to exctract your SQL from your java code and map the results of those statements to java objects.
Just to be up front, I will tell you now that I am NOT an O/R fan. :-) IMO, non-O/R solutions are better for situations where you have multiple data access points. If you are writing an application from scratch and the only access to your database will be through the application you are creating, Hibernate may work just fine for you. This assumes that you are totally sold on the O/R model (which I have said I am not). If on the other hand, if you have an existing application, mixing and matching Hibernate with other access methods (JDBC or iBATIS) is insanity. We are doing it here, and it has been painful at the very least. The other trade off is that database specific SQL is not Hibernate's preferred query language. It uses HQL, which while similar to SQL is not SQL. The benefit of HQL is that it allows you to switch databases easily because it is not database specific. In a commercial application, this is of value, because your customers can use it to deploy to any database. IMO it is of no value for an in-house application - when was the last time your business changed from Oracle to M$SQL on a whim? There are so many other things to consider in that process that the SQL is really a small part of it. Larry >>> [EMAIL PROTECTED] 04/07/04 12:35 AM >>> I don't think iBatis is a real ORM tool: is more an helper library for JDBC. You will always have to write your INSERT/UPDATE/DELETE statements, while Hibernate does that job for you (once written the xml mappings). IMHO hibernate is better if you have a very good db scheme and if you are not going to do massive INSERTS/DELETES. Or not? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
