思来想去，觉得自己的项目还是用ibatis好。
今天看到ibatis上的一篇文章，颇有同感：
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 Saikali