Hello, May be this comes just too late for you, but Manning (www.manning.com) just publised a book about Hibernate. It gives information on some of the problems you are mentioning below. It is also a good introduction on OR mapping.
Hugo > -----Original Message----- > From: Johannes Textor [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 09, 2004 4:19 PM > To: [EMAIL PROTECTED] > Subject: Re: Advantage using Hibernate with Cocoon > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
