I'll let the user community speak to the practical experiences, but at a practices level consider the following at a philisophical level.
All databases are legacy databases. Any database that is of any value will ultimately become a dependency for more than the original application it was built for. Inevitably other systems will start to report off of it, then perhaps write to it and ultimately will influence changes to the design. Unless they're all Java based applications using the same domain model and ORM, it's likely you'll run into the problem of a legacy design eventually, and the ORM will break down. In his blog[1], Ted Neward describes ORM as (forgiving the lack of political correctness) "The Vietnam of Computer Science"[2]. His point is basically that projects that start with ORM don't know what they're getting into, and eventually realize that it's a losing battle. It's a good point made in a very odd way. ;-) To be fair, I'll counter my own point: Designing for future need can be a bad practice too. It's counter to Agile methods and therefore you might be better starting with Hibernate and then moving to iBATIS if or when you need to. Cheers, Clinton [1] http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx [2] Ted is an American who has family that fought in the Vietnam war, so I won't judge the analogy. On 12/15/06, Ron Chan <[EMAIL PROTECTED]> wrote:
there's a lot of "advice" around that says hibernate is better when you have complete control of the data model, and ibatis is better when you are working on an existing database i would like to hear from people who has had good experiences with ibatis even though they are creating the data model from scratch, and how they feel it's been better for them than using hibernate thanks Ron -- View this message in context: http://www.nabble.com/ibatis-v-hibernate-tf2830264.html#a7901667 Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
