ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: iBatis and ORM's
Date Sun, 06 Nov 2005 03:44:02 GMT
Fantastic. Thanks for sharing Adib! I may even forward this on to a few
people.

Cheers,
Clinton

On 11/5/05, Adib Saikali <adib@programmingmastery.com> 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
> 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
>
>
>
>
>
>
>

Mime
View raw message