cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Textor <>
Subject Re: Advantage using Hibernate with Cocoon
Date Thu, 09 Sep 2004 14:18:39 GMT
Hi Pat,

I have am now finishing my first project I used Hibernate and Cocoon 
together in,
so maybe you are interested in some thoughts from a beginner's point of 

The issue Hibernate addresses is how to get objects to and from the 
database. When
I started to use cocoon, I was impressed by the possibility to separate 
design and
logic, using the sitemap and jxt/xslt for presentation and JavaScript 
flow control for
the control layer.

The most natural way to pass data to JX Templates seemed creating 
objects in JavaScript.
So I ended up writing objects - e.g. for articles sold in a web store - 
using JavaScript's
weird constructor syntax. The constructors used SQL statements to fetch 
the object's
data from a DB. Furthermore I had to define methods "update()" and 
"save()" for each
object to get the data back to the DB. These methods constructed SQL 
containing the respective values.

That was more a PHP-like approach, where you are used to getting and 
storing data using
self-constructed SQL statements.

Now the principal advantage of Hibernate is that it creates a new layer 
where all the
persistency stuff is handled. From my point of view, this has the 
following advantages:

- You can use "real" Java to write your business objects, there's no 
more need to use the
awful JavaScript syntax and it has all the obvious benefits like 
supporting interfaces,
inheritance, etc. (Well that's possible without Hibernate too, but 
Hibernate *forces* you
to do this.)

- The flow layer is reduced to what it is supposed to do, controlling 
application flow.
Complicated operations that are to be performed on the business objects 
can be implemented
as Java methods. If you are familiar with Javascript, you will probably 
agree that it is not
all too well suited for writing large and complex programs, due to the 
lack of proper code
structuring facilities. Therefore I think, the thinner the control 
layer, the better.

- It's easier to change the underlying database. When writing native SQL 
statements, one
often tends to use propietary DB features like, for example, MySQL 
fulltext search (since
it's just so much easier to use than java search engines :-) However, 
this cannot be ported to
Oracle or Informix, for example.

The main drawbacks I see are the following:

- Yet another Elephant you have to eat: The whole concept of persistency 
is by no means
easy to understand. There's also a lot of hibernate-specific things to 
learn, like the mapping
file syntax. Furthermore it's not a Cocoon component so it is 
non-trivial (although not too
complicated either) to integrate (for example have it use the Cocoon 
connection pooling
facilities). Yet I think it pays the price. Personally, it took me about 
two weeks to understand
the thing and get it to work.

- The hibernate query language, HQL, that you have to use for fetching 
objects that match
certain criteria (for fetching just one object there's a cool "load" 
method :-) is another obstacle.
Although it uses SQL-similar syntax whenever that's possible, it's still 
hard to learn since there's
only the official documentation available that cannot compete with the 
millions of articles and
books you can buy about SQL.

- Efficiency: The presence of another layer certainly does not make 
things more efficient. After
all, Hibernate queries and load()s have to be translated to SQL, too. 
But the most important point
seems to me that there are some subtile errors you can make that make 
performance a nightmare.
For example, I had an article database that also contained other objects 
like stores, images, common
article attributes and the like. For convenience, I implemented a lot of 
two-way associations to make
navigation easier (e.g., I can fetch all the stores for an article and 
all the articles for a store just by
calling a Java getTheThing() method).

Now when querying for ONE article, hibernate per default fetches EVERY 
transitively available
object, since you might do something like

article.getStores().get(5).getArticles().get(3).getStores() ....

and wow, now in fact the whole databases is fetched although you only 
wanted one article and
had no plans to navigate to a store !

Of course, this can be turned off, but IMHO it's a typical beginner's 
error :-) Just shows that you
have to think a little more when using Hibernate as opposed to native SQL.

Just my 2 Cents. I would enjoy further discussion.

Johannes wrote:

> I'm wondering what might be the advantage of
> using Hibernate - or another O/R mapper - together
> with Cocoon.
> There some articles on the web, about using
> Hibernate with Cocoon.
> And anyone using it?
> Pat
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message