Don't forget to add to the top, "You don't use stored procedures".
I haven't actually used it, but according to the docs for 3.0 version, Hibernate's support for SPs is weak, e.g., the stored procedure MUST return a result set for Hibernate to be able to use it (and that's all that it will use), and you have to do the configuration manually for it, no auto-generated config. Also, the documentation is unclear if you can pass record sets (or primitives even) as OUT params. -ed On 7/29/05, Jeff Butler <[EMAIL PROTECTED]> wrote: > When I was trying to decide on iBATIS vs. Hibernate for my current > project, it came down to this: Our DBAs require that all SQL sent to > production databases be reviewed/analyzed/tuned before being placed into > production. This forced us into "human written SQL" I think this is > not an uncommon requirement in any kind of reasonably sized system. > > We also have a domain model that is far different from our DB model - > that alone may have pushed me in the iBATIS direction. > > Maybe we should publish some kind of "Is iBATIS Right for My Project" > decision tree. I think it would look like this: > > If Your data store is a relational database > && You are not trying to reuse an existing database designed for > other applications > && Your domain model is a reasonably close match to your DB model > && Your developers have good control over DB design without DBA > "enhancements" > && Your DBAs do not require SQL reviews > && Your developers are weak with SQL > Then some kind of ORM tool (Hibernate, OJB, JDO, EJB3, etc.) could > possibly be right for you > Else - iBATIS is probably a better choice > > Not that I'm biased or anything :) > > Jeff Butler > >
