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 time. 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 queries. 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 queries. 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 it. Adib
