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.
Yeah, really, it's not that bad. As a Java programmer, I've come to find out as long as you make sure you don't use more memory than you need (i.e. nulling variables that are no longer useful), things run fine... ...correction. Things run fine so long as you don't use Swing. Swing needs a serious makeover (yes I'm aware of alternatives, but Swing just looks so dang cool when it works)
Before you mod me funny, think, perhaps I was insightfully funny?
Even in the presence of CLR/C#, I think Java will continue to be very strong and popular. Some things are cumbersome and awkward in Java, granted it has its warts, but on the whole it is very "ergonomic". There is a gigantic amount you can do in Java that will be easily understandable and maintainable by other Java developers. Your options are limited, but that's a feature. JDK 1.5 (ne 5.0) did expand the language a bit with generics, and there has been a lot of controversy over that, but on the whole Java remains rather simple, and a massive amount of libraries have been developed for it, many of which are continually folded into the core.
It's 10 PM. Do you know if you're un-American?
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
portability.
oracle is not the de-facto enterprise db.
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.
What I didn't like is the assumption that generating business objects from your mappings works well (or at all, in larger systems). I understand the argument for putting the business rules in the UI layer (Spring's controller objects, Struts actions) and letting the domain objects be simple DAO's, and I don't buy it for anything more complex than PetShop applications.
.java file. Fewer artifacts != lower cost of development/maintenance.
If you're writing a toy application or a simple database report generator, sure. You don't need complex business rules and it's probably easier to let someone generate DAO's and push what limited business rules there are into the UI layer.
If, however, you're writing a substantial business application, you've got four or five interfaces per deployment (UI, scheduler, import data API, erp interface, etc.). If all of those interfaces don't act against the same business rules enforced upon them, your customer's data is hosed and quickly. Anecdotally, all but one of the "data corruption" bugs in my last big project were from business rules that someone thought should go into the UI layer, and didn't get enforced for other interfaces, allowing usage of those interfaces to wreak havoc.
The other approach I've seen for generated DAO's is to hang business rule implementations off of the DAO's via inheritance. Not only is this approach contrary to the goal of inheritance, it prevents you from actually having object oriented classes. You'd better not try to have polymorphic behavior in those classes. The kicker with this approach is that your business rule classes are just as complex as if you'd simply written good domain objects in the first place, meaning that the generation has bought you no reduction of effort.
"The overhead of maintaining separate artifacts." is wildly inflated. The system details are there, whether conflated into the same files or separated into different files. You also have fewer artifacts if you don't separate interface from implementation. You also have fewer artifacts if you combine several classes into the same
Regards,
Ross
And HQL? Wow that's a great feature. Having to learn a mini language that looks almost like SQL and does the job of SQL.
Yeah, but you can't blame Hibernate for that idea. The whole Java world seems to love pseudo-SQL: EJB-QL, JDO-QL, etc.
where there's fish, there's cats