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!
Actually, this is one technology that kinda lives up to the hype. Its an ORM that performs (in most cases) as fast as hand-written sql statements. I call that powerful and ultra high performance...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
IMHO significantly better...but click and decide yourself
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 since it does not bring anything remarkably new or unique to the game; it is just too similar to Java for a switch to be justified.
As to whether "traditional" enterprise systems built in Java are "done fast"... Let's just say that its biggest drawback (always in the enterprise context) according to its opponents is the sheer complexity of developing, configuring and deploying any application of reasonable size. Hence the appeal of frameworks like Hibernate.
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/
Hibernate in Action is the best available I think. I flicked through "Hibernate: A J2EE Developer's Guide" in a bookshop and didn't think it would teach me much - however it might be a better book as an introduction to hibernate. (It certainly looked better than "Hibernate: a developer's notebook")
I did like HiA but it still left me wanting more. A lot of the book spent time talking about common design patterns where I would have liked to see a bit more Hibernate/DB theory.
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 known plusses and minuses.
Oh, and Hibernate works fine with a zillion SQL servers. Stored procedures only work with the one they're designed for.
Event Management Solutions : http://www.stonekeep.com/
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, Spring.NET and Maverick.NET.
Life is like a sewer; what you get out of it depends on what you put into it...
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 developer can take advantage of. Do you need these features?
EJB's do provide an object to relational mapping but that is only one aspect of the technology. Using this approach though forces you to communicate with another server for that communication. In my opinion the object relational mapping in EJB is lacking, and the 3.0 spec will hopefully address these issues.
Thus Hibernate was born. Hibernate does not require you to communicate to another server (RMI, Corba etc). Hibernate focuses on being the best object relational mapping tool out there. In my opinion it does an excellent job. However asking Hibernate to scale to the levels of EJB may be asking a bit too much.
The question that needs to be asked is what does your application require? Most will find that Hibernate meets the needs and as such it is doing very well.
NOTE: I am generalizing here. Please don't start a flame war. I am a fan of EJB AND Hibernate.
The more I learn about science, the more my faith in God increases.
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
Here are the other Hibernate books I've read (or skimmed):
Hibernate: A Developer's Notebook
Hibernate: A J2EE Developer's Guide (Addison Wesley))
Java Open Source Programming: with XDoclet, JUnit, WebWork, Hibernate
But they all fall short of Hibernate in Action imho.
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!
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.
The parent is exactly on the mark. The forced separation of deployer/developer roles in J2EE has caused me to do lots of useless busywork since I first started using it back in the 1.0 days. I'm a contractor, and have worked in a bunch of J2EE shops since then -- and not one of them has ever made use of the ability to tweak the sorts of configuration parameters you'd typically include in your XDoclet tags. But until XDoclet started catching on, they all had to endure the development overhead of maintaining separate configuration files and source files.
In addition, the parent is also spot on that using XDoclet doesn't stop you from changing the configuration at runtime! The system still reads the configuration files and they can still be tweaked at deployment time if need be. The only thing XDoclet does is save the developer from having to maintain all those annoying XML files by hand while coding.
If it still bothers you, just think of it as embedding default configuration information into the source. Most applications, I think it's safe to say, do that in one way or another anyway.
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 really well IF you have an object-oriented domain model that you want to persist as transparently as possible. While not part of the J2EE spec, it doesn't have to be - it works inside the container just fine. (Th main reason it is not part of the spec is political - the EJB vendors didn't want to have to write yet another component). IF you have an existing database schema, your mileage may vary with JDO - it is up the the JDO vendor to so support mapping tools to existing schemas. JDO 2.0 is not revolutionary - it just takes the existing stuff a little further. IF you like this approach, I would also suggest you look at an OODBMS like Versant.
3) Hibernate ROCKS, especially if you are mapping an existing database to a bunch of objects. It does a lot more than that though - you can start from objects and either generate or map to a schema, start with a schema and generate objects, etc. There is a fundamental 'impedance mismatch' between relational and OO, as the first chapter of "Hibernate In Action" outlines better than any explanation I have seen. It isn't a 'standard', but so what? You use standards when you want to choose between different vendors... This is open source, which is another risk-mitigation strategy for the same problem. 'Ant' isn't a standard, yet I doubt you could show me more than a handful of projects that don't use it (or Maven, which uses Ant under the covers).
In short, there is no one choice. All have their plusses and minuses, and any can be used in a J2EE environment even if they aren't 'part of the spec'. Even JDBC might be a valid choice given a particular project's needs. The choice is going to depend a lot on the application.
Sun realizes there is confusion, and is trying to address it... unfortunately, the letter they wrote to 'the community' actually added more confusion to the mix.
The next version of Entity Beans is going to look a LOT like Hibernate, but will use the new JDK 5.0 concept of 'annotations' to help describe the relational mapping. This will ultimately mean Hibernate will be subsumed into JBoss as their Entity Bean implementation (which is why they are a part of JBoss).
Sun also wants to have a persistence mechanism that is usable outside of a J2EE container. Entity beans in their current form are not it. JDBC can do this, but it is does not facilitate thinking in terms of an 'object model'. JDO is this spec now, as is Hibernate, and hibernate is actually moving to be more EJB-Like. My crystal ball says that Hibernate and JDO will unite under some uber-api umbrella that allows a developer to use it like either api can be used today, and will be a spec that can be used in a J2EE container as well as outside.