Larry
On 7/29/05, Ed Griebel <[EMAIL PROTECTED]> wrote:
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
>
>
