ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Meadors <lmead...@apache.org>
Subject Re: Does iBatis have a direct competitor?
Date Tue, 14 Feb 2006 17:14:23 GMT
On 2/14/06, Troy J. Kelley <troy.kelley@e-gineering.com> wrote:
> Your comment:
> " ORM tools expect that they and they alone update the database, and
> that all of the business logic is in the code. When things like
> triggers or other applications update other data, things get ugly
> fast."
> Is valid.  I think you could probably make the same statement for any
> persistence approach, right?  Anytime you have another process (a
> trigger or otherwise) updating the DB outside of your application, you
> can run into issues.  This is where different locking strategies come
> into play, if I'm understanding your statement correctly.  I might use
> an optimistic locking strategy if I know there could be outside
> processes updating my data.  I would use this strategy whether I'm doing
> custom JDBC, ORM or iBatis.

I think we are in agreement on most points, but not all...not quite yet


In my mind, the difference here is how involved the persistence
approach is with the database and the application.

With iBATIS, you essentially just get JDBC (or ADO in the case of
.net) made smarter. It provides some simple caching, makes your SQL
creation external, eliminates Connection/Statement/ResultSet
management, makes it easier to do ResultSet <-> Object and Object <->
PreparedStatement mapping...and that is about it.

>From what I have read and experienced, most ORM tools want to
*replace* the database: For example - swap SQL for HQL (or build
queries with Java objects), eliminate data access code, and replace it
with "transparent" data access (which was another issue in the app I
mentioned earlier in this thread).


View raw message