Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Databases Software Data Storage Programming Book Reviews IT Technology

Hibernate - A J2EE Developers Guide 244

Posted by timothy from the go-back-to-sleep dept.
Simon P. Chappell writes with a review of the Addison Wesley-published Hibernate - A J2EE Developers Guide. "To quote the project website: 'Hibernate is a powerful, ultra-high performance object/relational persistence and query service for Java.' To quote the back cover of the book: 'Now there's a practical, hands-on guide to using Hibernate's flexible, fast object/relational persistence and query services.' Phew! What a lot of spin packed into two sentences. Let's take a look and see if it delivers." Read on for the rest of Chappell's review.
Hibernate - A J2EE Developers Guide
author Will Iverson
pages 351 (13 page index)
publisher Addison Wesley
rating 7
reviewer Simon P. Chappell
ISBN 0321268199
summary Overall a solid work

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 Consider

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

Summary

This 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.
This discussion has been archived. No new comments can be posted.

Hibernate - A J2EE Developers Guide More

Hibernate - A J2EE Developers Guide

Comments Filter:

  • Chapelle? (Score:2, Funny)

    by blackmonday ( 607916 )
    I'm programming Java, bitch!

  • A few things... (Score:5, Informative)

    by FortKnox ( 169099 ) on Wednesday April 06, 2005 @04:14PM (#12159019) Homepage Journal
    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.

    • Re:A few things... (Score:3, Insightful)

      by rossifer ( 581396 ) *
      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.

      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 ea
      • I have such a complex applicaiton. I recently refactored to make my DAOs stateless. I already had my logic in other objects where it shoudl be.

        dividing the responsibility of an object is fundamental to OO programming.

        Just because the rules are not in the dAO does not mean the end up in the UI. Add another layer.
        • dividing the responsibility of an object is fundamental to OO programming.

          Exactly. Let Hibernate build the DAO's for you behind the scenes. Those will manage the data in and out of your domain objects (that can then focus on enforcing all of the business rules) and all you have to do is maintain an .xml file (if that).

          Don't build yet another DAO layer for Hibernate to manage with Hibernate's automatically generated DAO classes. The DAO pattern doesn't let you use encapsulation, effective inheritance,
      • Business rules in the UI layer? WHAT? That's a recipe for disaster. Add another layer. Spring controllers and Struts actions should *NOT* contain business logic, but call objects that do. They in turn can talk to the db.
        • Business rules in the UI layer? WHAT? That's a recipe for disaster.

          Exactly.

          Domain objects with business rules, Hibernate builds the DAO's behind the scenes, UI presents the data from the domain objects to the world.

          I'm objecting to going through the effort of describing DAO's for Hibernate to synchronize with the db and then having another place for your business rules. Hibernate takes care of the same problem that DAO's purport to solve and does without me needing to do anything other than maintain a
    • This book, however, I found extremely lacking.

      Then try Hibernate in action [amazon.com] (but if amazon prompts you to buy Hibernate : A Developer's Notebook [amazon.com] as well, skip it. The latter is a typical beginners book. I had the misfortune to buy them both AND read Hibernate in Action first, only to find out that reading the other is useless after that)

  • Is it better than Hibernate in Action? (Score:5, Interesting)

    by Babar ( 2466 ) on Wednesday April 06, 2005 @04:22PM (#12159097) Homepage Journal
    I can't believe a review of a book about Hibernate would not compare it to the book everyone recommends, Hibernate in Action [manning.com]. 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.

  • Java never got a fair break. (Score:3, Interesting)

    by Future Man 3000 ( 706329 ) on Wednesday April 06, 2005 @04:28PM (#12159165) Homepage
    People tend to notice its flaws (oh it's so slow!) because it's the first iteration of its technology, but it is still an excellent tool for getting the job done regardless of its platform.

    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.

    • The main use of Java today is in large scale enterprise applications, usually meaning J2EE, although the current trend is the use of lighter alternatives, namely JSPs/servlets coupled with frameworks like Spring and Hibernate.

      This development itself proves the big advantage Java has over C#/.Net in the enterprise arena: a far wider array of supporting libraries and frameworks, not to mention a selection of mature application servers. For this reason it will be quite hard for C# to catch up, especially sinc

      • This development itself proves the big advantage Java has over C#/.Net in the enterprise arena: a far wider array of supporting libraries and frameworks, not to mention a selection of mature application servers.

        This is bound to be the case, considering how much longer Java has been around compared to C# - however, bear in mind that a large number of popular frameworks have already been ported to C#/.Net including NHibernate [sourceforge.net], Spring.NET [springframework.net] and Maverick.NET [sourceforge.net].

    • Re:Java never got a fair break. (Score:5, Insightful)

      by Hard_Code ( 49548 ) on Wednesday April 06, 2005 @04:46PM (#12159332)
      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.
      • I hate hate curly braces, and any other non alpha-numeric clutter that pollutes my code reading/writing space. And now we enter python/ruby. No matter how may technologies there are for Java, unless I have to explicity use it, I won't.
        Don't get me wrong I don't like writing english for code like cobol either. But if language institutes good layout format for all developers, I'm all for that. Let rest of languages participate in obfuscation contest and be winners, because thats
        what all those punctuation mark
        • If you're writing software in a business environment, popularity is directly related to how easy/cheap it is to get ahold of programmers who have experience in a given area.

          It's easy to find an adequate Java programmer. Not so much for Python, Ruby, or Lisp.

          Of course, just like any other profession out there, good programmers are hard to come by regardless of language. Good programmers could get rolling in any of the languages I mentioned in a couple days anyway.

          The business world mostly gets away with a
    • I tried to give it a fair chance, but then i found that it had no unsigned data type... I'll stick to C++, where we got real types and real templates. (none of that fake stuff java/C# does)
      • C++, where we got real types and real templates

        C++ has neither real types or real templates.

        C++ types are system and implementation dependent, and the temples are an imitation of something done better elsewhere (i.e. CL macros).

        And BTW, Java does have an unsigned data type.

    • The main problem was that the first JVMs from Sun were outright dumb (it wasn't until 1.3 that they actually included a good JIT in it). First impressions are strong.

      Current JVMs are reasonably fast. In fact, most performance gap between java and C comes from its safety features.

      Safety, however, is very important for web apps. Writing regular sites in C is just asking for C-style memory attacks, like buffer overflows.

      Finally, nobody really complains about python's or perl's speed.

    • Is it going to be replaced by C#? Perhaps,...

      Doubtful. I'm sure C# will get quite popular, but neither that nor will Mono have a foothold on the server like Java does anytime soon. Java's tools and microcosm of open and closed projects are being used by quite a bit by companines and organizations doing real, every day work. Granted, Java on the desktop never took off, but the whole C# vs. Java war is just a myth - there's plenty of room for both to exist.

      I'm using Hibernate on my current project and whil
    • Yeah, Java got a bum rap early on for speed. But people quickly showed that in many of Java's preferred domains, I/O latency was by far the primary reason for speed issues.

      Then, people starting coding GUI apps in Java, with a misguided notion that it would be truly portable GUI apps. This is not only untrue, but a lot of people got angry because their sluggish machines couldn't handle it. This continues even today. A common comment about Eclipse, for example, is that it's a terrific IDE so long as you have
    • The competition for java is not C#. Let's face is there isn't a whole hell of a lot of difference between them. The competition is from python and ruby.

      Hibernate may be great but all the buzz these days is about ROR (ruby on rails). It takes a completely different approach to persistance layers and it still a bit immature but it has potential and some great brains behind it.

      While java is looking over it's shoulders at C# languages like python and ruby are becoming more ubiquitus.

  • Hibernate and J2EE (Score:2, Interesting)

    by cmiles74 ( 167687 )

    I am curious to know if this books spend a decent amount of space on actually using Hibernate in the context of a J2EE application (i.e., instead of using CMP)? I currently work with CMP and I am not a huge fan, I am very interested in alternatives and wonder if this book is the place to start looking.

    The title of the book implies that the book does cover this, but the review doesn't actually mention this specifically.

  • Hibernate vs. JDO vs. EJB (Score:3, Interesting)

    by prakslash ( 681585 ) on Wednesday April 06, 2005 @04:29PM (#12159193)

    What is the latest on this battle?

    There are so many soundbites floating around:

    Hibernate is JDOish but does not follow Sun JDO Spec. But.. Gavin King of Hibernate became a member of JD02.0 Expert Group and would make it compatible with JDO 2.0 Spec.

    JBOSS is adopting Hibernate as the underlying persistence mechanism for its Container-Managed Entity Java Beans.

    EJB 3.0 rejected JDO 2.0.

    So.. now I am confused. Who is the winner? Should I buy the book or not? Anyone care to enlighten us?

    • A related question, one I get all the time from DB guys I know, is, "why are you putting all this persistence logic in the application instead of the DB (i.e. stored procedures)?". Can someone come up with a snappy comeback for me? I've been developing with java for less than a year.

      • Re:Hibernate vs. JDO vs. EJB (Score:2, Insightful)

        by Anonymous Coward
        portability.

        oracle is not the de-facto enterprise db.
        • portability

          Mod parent up. It's not caching. Databases can cache too. If you're an ISV and you want to sell to companies that don't neccessarily share your views on which DB vendor is the best, then stay away from stored procedures and make your SQL as standards compliant as possible. In which case, an ORM technology makes perfect sense.

      • My main reason for going with Hibernate is... it's java. It's iwthin the J2EE appserver environment, deployment to it is identical to deploying any other J2EE component. Package it up, drop it in the deployment dir, and you're off and running.

        Shifting persistent objects into anything other than a standard SQL engine means you have to undersgtand and work with 2 different technologies when manipulating your persistence engine.

        Frankly, I'd like to stay with one language, one deployment method, one set of

      • Re:Hibernate vs. JDO vs. EJB (Score:4, Funny)

        by scrotch ( 605605 ) on Wednesday April 06, 2005 @05:07PM (#12159532)
        Tell your DB guys that the word from above is that your database vendor will be changing. Be vague enough that they worry...
    • Here is my understanding of it.

      Hibernate does not really compete with CMP Entity beans, but perhaps sessions beans. I see the breakdown as this.

      If the requirements are hundreds of transactions a second, then EJB will probably be the best choice. It has the ability to swap out objects to disk and share resources very well. In my humble opinion it is the only way to scale Java apps up to many thoughsands of concurrant users.

      With EJB's, the container handles and provides a ton of features that you the de

      • Re:Hibernate vs. JDO vs. EJB (Score:4, Interesting)

        by koreth ( 409849 ) on Wednesday April 06, 2005 @06:23PM (#12160258)
        Hibernate does not really compete with CMP Entity beans, but perhaps sessions beans.

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

        Hibernate does not require you to communicate to another server (RMI, Corba etc).

        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.

        • Excellent points. I definately have a lot to learn about EJB 2.x and Hibernate. I still stand by my point though that EJB is "generally" on a separate server and communicated to, where Hibernate is used in the local JVM. I also stand by the point that the core reason for EJB is scaleability.

          From my limited test with Hibernate I have found it to be a HUGE memory hog. Specifically RAM. Now given that the app is not distributed, RAM can become an issue. I also want to point out that when the system fina
        • Can the same Hibernate objects be used from different web applications? let's just say that I have one database, but multiple web applications running in the same application server. How does Hibernate solve the problem of data integrity across different web applications? Last time I checked (and Hibernate was rejected by my company for this reason alone), if I have some information in one Hibernate session, then other Hibernate sessions might be unaware of the changes in the database made by other web appl
      • Thousands of transactions on what ? Mainframe? A PC? an AMD server? PIII latop? Quad xeon server. Sorry speed metrics in software systems has to be backs against a hardware unit, otherwise they are useless.
        And transcation can include X amount of queries.
        thanks.

        PS: someone on slashdot should enable Spell check button, since so many people are out of English speaking states. Maybe make it a requirenment... :)
        • First, I am sorry about the spelling.

          You are correct about transactions. However my point is fairly general, in that if you want to have a system scale (say 75% database reads, and 25% writes), at some point Hibernate will not be the answer. My experience is that Hibernate is RAM hungry, and EJB's are a pain to debug and develop. No solution is perfect, but Hibernate and EJB's don't really compete against each other.

      • I don't see how Hibernate competes with Session beans, as it's Entity beans that handle the persistance layer of your app. In fact, I've read several articles about using Hibernate as a replacement for Entity beans, and using a Stateless Session bean facade to work with your Hibernate objects. This way, you get all the bennies of a J2EE app server and EJB (Scalability, declarative security, declarative transaction management, connection pooling, JNDI services, JMX services, messaging services, etc.) witho
        • Excuse my ignorance, but couldn't you have used session beans and done the O/R mapping yourself? Then within that session bean used some of the CMP entity beans, when needed?

          I don't have much time right now, but I would love to talk more about this with you and see what issues you found, and how you solved them.

          Thanks
          • I had considered a "hybrid" type solution where I use Entity beans for inserts and updates, and some other method (ORM/SQL called from POJO's, etc.) for constrained lookups. However, I think that I'd be doing a lot of redundant work for this (i.e. defining an Entity bean to represent a product, then doing a ORM object for representing a product). I'd rather just use one framework for handling persistance. If you have an example of how you've done something like this in the past without too much pain, plea
    • Should I buy the book or not? Anyone care to enlighten us?

      Well, with a name like Hibernate, I figure the book would put me to sleep.

    • Hibernate is JDOish but does not follow Sun JDO Spec. But.. Gavin King of Hibernate became a member of JD02.0 Expert Group and would make it compatible with JDO 2.0 Spec.

      Gavin King is actually on the JSR 220 (EJB 3.0) committee and has completely thumbed his nose at JDO. He has posted on TheServerSide.com about how much JDO sucks. EJB 3.0 completely embraces Hibernate. In fact Hibernate 3.0 + Annotations is an implementation of EJB 3.0.

      JBOSS is adopting Hibernate as the underlying persistence mechanism

    • mmmm JDO. I switched from Hibernate to JDO last year and love it. I have always avoided EJB, preferring Jini should I need to build distributed systems, and POJOs with JDO (or Hibernate, honestly it's 6 of one, half dozen of the other). The big plus for JDO is there are loads of JDO vendors competing and so far it's been prety much plug'n'play to swap out one JDO impl and use another. JDO2 is really flexible, much more so than Hibernate IMHO and the whole i really dig the byte code enhancement idea a wh
    • This is a complex minefield I have been navigating for a couple of years. HEre is my understanding of it:

      1) When we talk about EJB 3.0 in this context, we are really talking about Entity Beans. Entity Beans are currently crap - do not use them. Future versions of the spec are moving in a better direction though (see below). The Session Beans part of EJB 3.0 are very useful IF you need to services provided by the container (but that is outside this conversation).

      2) JDO is a real thing, and it works rea
  • If you think Hibernate is good, then try Cayenne and really be blown away.
    I am not affiliated with Cayenne at all - just a VERY satisfied customer.
    http://objectstyle.org/cayenne/ [objectstyle.org]

  • XDoclet? (Score:4, Insightful)

    by coyote-san ( 38515 ) on Wednesday April 06, 2005 @04:55PM (#12159417)
    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.
  • Now we're going to see the Java equivalent of emacs vs vi: Hibernate vs EJB vs JDO.

    If you wanted those flame wars, you could just head over to theserverside [theserverside.com]

    But on a slightly more serious note, it seems that there are moves afoot for reconciliation between EJB and JDO. There's a link with discussions here [theserverside.com]. Enjoy the reading. theserverside does have some infamous trolls and makes slashdot look like the greatest thing since sliced bread.

  • Sqlmaps (Score:5, Informative)

    by Espectr0 ( 577637 ) on Wednesday April 06, 2005 @05:42PM (#12159857) Journal
    For those of us that want a simpler, faster, easier to use framework and just want to map your own queries to objects, <URL:http://www.ibatis.com/> is much better. And for those that like .NET it is available in that platform too.

    Here's an example on how to execute a query called "myquery"

    MyObject myobject = (MyObject)sqlMap.queryForObject("myquery",myintege r);

    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
    • iBATIS looks at first glance like Teh suck. Where's the basic documentation?

      ie, From the front page of http://www.ibatis.com/ [ibatis.com] click on the small "Wiki, FAQ, IRC" link. Near the bottom of that page, locate a tiny "FAQ" link and click it, and go to a page that tells you that "Frequently 20Asked 20Questions This page does not exist yet." And suggests I try "Frequently Asked Questions" instead. Click this, and at long last you get to the FAQ

      - The FAQ does not answer the questions "What is iBATIS?", "What doe
  • Hibernate's fans say it's the "right" way to handle extremely large, complex data models, especially if they already exist.
    What you have to do is write yourself a new Java class (according a to big complex set of rules), one for each entity in the model. And there are a lot of different ways to handle various association-types and cascading-persistence requirements.
    Once you've done all this, you have Hibernate's methods for "easily" loading and saving the objects.
    So in a way you have to re-express an alread

Slashdot Top Deals

Business is a good game -- lots of competition and minimum of rules. You keep score with money. -- Nolan Bushnell, founder of Atari

Close