ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Medium <contactm...@gmail.com>
Subject Re: iBatis and ORM's
Date Sun, 06 Nov 2005 12:04:54 GMT
Hi Adib,

Thanks for sharing such a detailed account of your experiences. Did you 
ever run into any problems with the object identity hashCode/equals 
issue with hibernate. I know the hibernate people keep saying this is a 
general java issue (which I understand) but I find it a major reason for 
not using it. It just tells me that object identity in orm (and really 
therefore orm) is flawed. It just doesn't feel right. This is why i love 
and continue only to use ibatis. It keeps things simple and there are no 
ambiguous use cases which leave the user bewildered in terms of what the 
heck is really happening underneath the covers.


Adib Saikali wrote:

>Here are is a record of my experiences with Hibernate on a recent web
>project where I was the team lead and had complete control over choice of
>technology. This message is in the spirit of theory vs. practice. 
>A wise programmer once told me that "Simple things should be simple and hard
>things should be doable". I was recently on a new project where I was the
>team lead and I made the choice to use hibernate. This was my first serious
>hibernate project and I found out that in Hibernate simple things are not so
>simple but the hard things are theoretically made easy by hibernate.
>However, I needed the simple things 80% and the hard stuff about 20% of the
>In my particular situation I had a very well designed data model that was
>built by a highly experienced data modeler. The data model was built a
>couple of weeks before I joined this project as the team lead and it had
>about 90 tables. 
>The task of mapping this data model to hibernate was not very easy, in the
>end we went with a one table one class mapping. We had many association
>tables that carried the reasons why the association was there in the first
>place. So we had to expose the association tables as mapped hibernate
>objects (This was also the recommendation of the Hibernate in Action book). 
>Developer productivity was the number one priority on this project, because
>we had a very tight deadline which we met). The idea behind ORM is that the
>developers would have only had to deal with the Java Objects but alas that
>was not doable they all ended up with print outs of the data model on their
>desks. After my experience with this project I do not sure that the goal of
>cleanly separating the 
>Also many of our web pages had data on them that was very easy to grab via
>SQL however it would have required a lot of code to traverse from one java
>object to another to present those pages. Following the advice of the
>Hibernate in Action book we ended up using report queries to get our data
>out of the database. Almost every screen that we did had one or two report
>The interesting thing is that the report queries in Hibernate turned out to
>be more complex to write and figure out. We frequently had to write queries
>in SQL then convert them to HQL. The whole idea of hibernate taking care of
>generating the SQL for you did not pan out. We still had to write a lot of
>Many of the tables we had a lot of relationships to many other tables and I
>frequently found out that I could not map those relationships very easily to
>hibernate. At first I was tempted to go to the data modeler and ask him to
>change the relationships to make the hibernate mapping easier. The more I
>understood the business problem the more I figured out that he had done a
>great job and it was pointless to change the data model to try and make it
>more hibernate friendly. For the record the data modeler was great to work
>and he did not object to any changes that we requested. 
>So I made the decision not to map the complex relationships to hibernate.
>Only simple relationships got mapped to hibernate, and this another
>disappointment for me with ORM & Hibernate. It just seemed that I was always
>trying to fit a square into a circle. 
>In the end I had one java class for each table in the database, only simple
>relationships were mapped. Complex relationships were not mapped and that
>simplified our project quite a bit and allowed us to get in on time. So we
>needed up with a lot of report queries in HQL which made use of the new
>operator in the HQL to stuff the results into java objects. 
>At the time I started this project I did not know much about iBATIS and I
>knew a lot more about Hibernate. Developer productivity was one my keys
>goals and I figured that it would be easier for me and my team to have
>access to books on hibernate and there were more learning resources for
>hibernate. If I was doing this project again I would have probably gone with
>iBATIS since I eneded up using hiberante the iBATIS way!
>My intuition as a programmer is that mapping statements to classes is better
>than mapping classes to tables, simple because it more naturally fits the
>principle that "simple things should be simple to do and hard things should
>be double." 
>One of the key features of SQL is its clousure property every SQL query
>returns a table. If some one was making an Object Query language they would
>not be able to keep the colsure property or do projection in way that makes
>sense. This is why I think that mapping objects to statements is a better
>approach than mapping objects to tables. 
>I hope the write up of my experience was worth the time you spent reading

View raw message