I'll share my story on this, too, but will say up-front that I am (obviously) an iBATIS advocate.
I was an early adapter of ORM. I started with Hibernate 1.x before I had ever heard of iBATIS. After a week or so a friend (who had also used ORM - in the form of JDO) warned me that I would not like it, and mentioned iBATIS. I didn't listen and decided to try it anyway. What I found was that much of what I had learned over the previous 10 years about database design and SQL query optimization was thrown out the window, and I had to learn a new query language..that would generate my SQL for me. The problem was that it was just as complex as SQL was, just nowhere near as much had been written about it. Next, I learned that I could not get a value out of the database, I could only get an object. No customer name, just a customer object. Not real high performance, but it was still easy. Then I discovered that if I wanted to join tables, I could still only get objects out - so in the case of a join, I would get a List of Object arrays. At that point, I started to think that maybe this wasn't such a great idea, because I had to hard code the HQL into the application, and also hard-code the array index to get to the correct object once I got the array from the list - so for example, myJoin[0] is customer, and myJoin[1] is order. I was beginning a new project, so I spent about 2 weeks writing a prototype application using ORM to test it out. I was not very happy with the design that I was forced into, so I decided maybe my friend was right, and downloaded iBATIS to see if it would make things easier. After about 2 days, I had replaced the entire data-access layer, and my "stale object" exceptions all went away, performance was improved, and all of the other developers already knew how to use it because it was just SQL. So IMO, I do not agree that ORM (not just Hibernate) is better if you have complete control of the data model. I DO believe it is better if you are building a single-application database (no sharing with others, no external reporting) *and* you have developers with little or no knowledge of SQL or database design. I'll even disagree with Clinton that "Designing for future need can be a bad practice too", or maybe just emphasize the "can" - IMO, our value as developers/consultants is based on our ability to look ahead and see troubles before they arise (so, I am glad to see questions like this on the list). I liked the Vietnam analogy, because in my experience, ORM was a total quagmire. It was also VERY messy to refactor out of an application once it had permeated it. Larry On 12/16/06, Clinton Begin <[EMAIL PROTECTED]> wrote:
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. > >
