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 view.


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 statements
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.

Greetings,
Johannes

[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to