Slashdot Mirror
Hibernate - A J2EE Developers Guide
What's To Like
The first thing that I liked is the way the book is written. Mr. Iverson has a very pleasant writing style that I found engaging. Not too formal and not too light. Naturally, there is a certain amount of Hibernate evangelism, but hey, if the author doesn't like the tool, then how am I supposed to feel good about it either? The evangelism does not feel like it strays from the bounds of truth, and there is much honesty in his first and last chapters where he discusses reasons for using a tool like Hibernate, and how Hibernate has influenced the design of the soon-coming version 3 of the EJB standard from Sun.
Chapters two, three and four cover the basics of using Hibernate. Each covers a different aspect, and each is independent of the other. Chapter two covers the use of the Hibernate mapping file as the reference that everything else is built from. This is the recommended mode of operation, where the database schema and data access objects are built for you. Chapters three and four are for those of us in the corporate world where the code or the database schema comes first and we have to adapt to and accommodate it.
Chapters seven and nine give the database theory-challenged amongst us a useful refresher in database relationships and transactions. The information, while provided in the context of Hibernate, serves as a useful refresher for the rest of us.
Hibernate has three query mechanisms. Given its relational database capabilities, one of the options is the use of plain old SQL, naturally. The two remaining options are the Hibernate Query Language (HQL) and the Criteria API. The HQL gets a fairly decent amount of coverage and left me to infer that it is the preferred means of expressing queries. The Criteria API gets only four and a half pages of explanation, which is still more than the single page dedicated to SQL.
The next to last chapter is a collection of real-world advice and tips for getting the best from Hibernate. This is a very useful chapter and looks like it contains good advice. The only thing I would suggest is that it's a little slim for a chapter of its own. Either the information could have been tucked in an appendix, or it could have been spread through the book in the form of embedded tips.
Naturally, the book has a website to accompany it.
What's To ConsiderThe book carries a copyright date of 2005 and a first printing date of November 2004. That being said, it should come as no surprise that the version of Hibernate covered is 2.1.2, but at the writing of this review (early April 2005) Hibernate 3 went final. I feel that the majority of the concepts and basic operations will be unchanged, but take this into account when deciding upon a purchase. While it is difficult to write books against the constantly moving target of an open-source or free software project, it is possible. I was involved in the technical review of a number of Struts books and they were challenged with the task of being available as version 1.1 was released. A massive undertaking, but one that they proved doable.
The typesetting seems crowded in this book. I'm not a white-space extremist, but I sure recognise when there's too little. The listings are often multi-page and have a slightly squashed feel to them.
Depending upon your point of view, chapter five is either a very useful annotated explanation of all of the available mappings within Hibernate, or it's a bad case of using available online documentation as filler (53 pages). Personally, I dislike this, but if you're in the market for an "all-in-one" style of book, this might work for you.
SummaryThis is a solid work that will take you from novice to a good working knowledge of Hibernate. If you can live with the fact that the book targets Hibernate 2.1.2 while the current production version available from the website is 3.0, then give this book a try.
You can purchase Hibernate - A J2EE Developers Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Hibernate, first of all, is becoming the de facto persistance layer for all modern java webapps. Tied up with the Spring Framework for transactions and either Struts or Tapestry on the front end, it is becoming a commonplace for tons of Java work.
This book, however, I found extremely lacking. It didn't really teach me anything new that I didn't already learn from the webpages. Granted, I've been using hibernate for over a year now and have kept up with the technology, so perhaps this is still a book for someone new to the technology.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
I can't believe a review of a book about Hibernate would not compare it to the book everyone recommends, Hibernate in Action. HiA is a great book, written by people who work on the project, including the lead developer. Of course, this review doesn't have much information that couldn't be obtained from skimming through the table of contents on Amazon.
Yours was a powerful, extremely engaging post that I found chock-full of interesting and insightful commentary!!!
Ironically, the word ironically is often used incorrectly.
Is it going to be replaced by C#? Perhaps, but it is possible to fully exploit it today, and with tools like Hibernate it's possible to rapidly deploy applications on a grand scheme. In today's business environment it is often a matter of getting it done fast rather than best, and if it's turning into a problem with performance it is always possible to turn to another language once you have something in place.
I never vote for anyone. I always vote against.
-- W.C. Fields
if (java.performace >= c.performace) I.eat_hat();
Bleh:
push ax
push bx
push cx
call test_speed_C
move di,cs:[ofs_testC_result]
move ds,cs:[seg_testC_result]
move al,ds:[di+2]
call test_speed_asm
move di,cs:[ofs_testC_result]
move ds,cs:[seg_testC_result]
move ah,ds:[di+2]
cmp al,ah
jb bwahaha_msg
pop cx
pop bx
pop ax
Chicks dig asm, but I'll concede it's so-so for rapid prototyping though...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
The most important unanswered question: does it discuss XDoclet?
I know, many people like maintaining configuration files manually. Some people also like nailing their tongue to flaming coals.
Personally I prefer using a handful of @hibernate and @spring tags. But I haven't found a decent explanation of how to use the tags (e.g., if you use A you must also use B). It can be annoying - I only recently discovered the @hibernate.joined-subclass tag that permits me to use a common base object (for an integrated 'id' space) without creating a "kitchen sink" monster table.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Well, Hibernate isn't an SQL writer. It's for translating between RDBMS and Objects. It's very good at persisting objects and getting objects from a database. It's very good at pulling large graphs of associated objects, which is a pain in the ass to do manually and difficult to do well (for me anyway).
Although it's possible to do summaries, it's not what it's for primarily. I think you'd be better off polishing up your SQL rather than learn Hibernate if that's what you're doing. Not that it would be any worse than what you're doing now (you could run the same SQL through it), it just seems like you could get bigger improvements from the time you'd spend learning it.
Tell your DB guys that the word from above is that your database vendor will be changing. Be vague enough that they worry...
My quick recipe for that is:
1. Screw EJB and CMP
2. Use Spring instead of EJB's (or in conjunction with EJB's)
3. Use Hibernate for persistence
4. Configure Hibernate through Spring and use the Hibernate ORM support in Spring to further speed up development and decrease code (both Java AND xml)
Go hug some trees.
Hibernate is the most recommended solution.
Depends what for.
In spite of what you might read, JDO IS widely used, which was why the JDO 2.0 specification was recently approved against a lot of political pressure.
JDO does not limit you to relational stores. Hibernate does. JDO 2.0 is very close to Hibernate in terms of use and features, but can work with a very wide range of stored. You can get JDO implementations that work with CSV files, Object databases, XML stores etc. You can use exactly the same code and API to access these stores as you use to access relational stored.
Hibernate is a high-quality product, but JDO gives you choice.
There are nice free and open source implementations of JDO as well.
For those of us that want a simpler, faster, easier to use framework and just want to map your own queries to objects, is much better. And for those that like .NET it is available in that platform too.
e r);
Here's an example on how to execute a query called "myquery"
MyObject myobject = (MyObject)sqlMap.queryForObject("myquery",myinteg
And here is the query declaration:
<select id="myquery" parameterClass="java.lang.Integer" resultClass="mypackage.MyObject>
select * from mytable where id = #value#
</select>
Simple query to object mapping
Open Source Java Web Forum with LDAP authentication
From the Hibernate homepage:
The Hibernate Query Language, designed as a "minimal" object-oriented extension to SQL, provides an elegant bridge between the object and relational worlds. Hibernate also allows you to express queries using native SQL or Java-based Criteria and Example queries.
So...I'm guessing you're using the phrase "SQL writer" in some new and unusual way. Does "SQL writer" mean "writes SQL output to standard output"? Do you mean "SQL optimizer?"
Hibernate can only talk to RDBMSs that use SQL. It writes SQL to them and recieves SQL from them.
Mod me down and I will become more powerful than you can possibly imagine!
I disagree -- Hibernate is almost a drop-in replacement for CMP entity beans. It does nothing to address the issues that session beans address (implicit transaction management and transparent load balancing, to name the two big things session beans buy you) and does the important thing CMP entity beans do (O-R mapping and removing the need for an object to have code to load and save itself.)
Neither does EJB, especially as of EJB 2.0. Using local bean interfaces means no RMI overhead -- they're so against you using remote invocations that local bean methods are forbidden from throwing RemoteException!
Not, mind you, that I'm any big fan of CMP entity beans. Using them was the biggest architectural mistake I made when I was starting out in J2EE development. Lots of development overhead, bad performance, and very little real gain. Hibernate beats CMP entity beans in just about every respect.