On 2/14/06, Troy J. Kelley <[EMAIL PROTECTED]> 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 :-D 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). Larry
