About Hibernate Q&A
What is Hibernate for?Hibernate is a persistence service that stores Java objects in relational databases - or provides an object oriented view of existing relational data. (Hibernate also does some XML data binding!)
Theres plenty of tools that do that ... container managed persistence, for example!When I say "Java objects", I really mean it. Some persistence frameworks allow you to persist certain classes written in an unnatural, semi-object-oriented style. Hibernate is designed to persist just about any Java class, designed and implemented using natural OO/Java idiom (inheritance, association, composition, collections). There are other tools that do this, but we think we have the best approach for a certain range of problems and for a certain programming style. Hibernate is so flexible you can retrofit persistence to just about any business object with minimal code changes. Here's some highlights: Hibernate can persist most JavaBeans with no code changes to the bean. Hibernate can persist a graph of instances of user-defined classes to a single table row - this allows an ultra-fine-grained object model. Hibernate can support lazy loading (via the proxy pattern) for classes that do not implement an interface!
What do you mean by "service"?Some persistence layers work by imposing a certain design upon the classes to be persisted. I'll call this the framework approach. CMP is a good example. The framework calls into the business domain objects; the framework is the client. Typically these kinds of approaches provide a managed environment in which the objects are instantiated. In some cases (eg. entity beans) it is extremely difficult to run the code without that environment. Such approaches often have a slow compile-test-debug cycle which increases development costs. Secondly we have found, at least in the case of EJB, that they often lead to strange and unnatural implementation styles. On the positive side, it is easier for the framework code to control concurrency, security and memory allocation. A persistence service is an interface that is called by the application logic; application logic is the client. A great advantage of this approach is that the business domain objects might be implemented so they can run without the persistence layer. For development methodologies that stress automated tests and programming by intention (eg. eXtreme Programming) this is a great advantage. Even many old-school SmallTalkers and developers from scripting backgrounds swear by a programming style which emphasises rapid test-debug iterations, rather than trying to get things right the first time. So how can we get the best of both worlds? Easy! Use a Session EJB to control transactional scope, security, threading and remoteablity. Use Hibernate for persistence. Arguably, the J2EE architecture went wrong when it tried to address too many separate problems with a one-size-fits-all solution. Most business objects are too fine grained to make good entity beans. On the other hand, if you are really keen on entity beans, try using Hibernate for BMP - then you will at least get some proper dependent object support.
Why use runtime reflection? Every persistence mechanism needs a generic-programming mechanism for accessing attributes of the objects it persists. Serialization uses reflection. CMP uses code generation. JDO uses byte-code processing. We strongly believe that reflection (or CGLIB-style runtime byte-code generation) is the right tool for the job. Runtime reflection removes the extra (often very slow) step from the build process. And, at runtime, reflection isn't really as slow as people say. Compared to the interprocess (possibly interhost) communication and disk IO involved in every database access, reflection is lightning fast. If you don't believe me, consider the fact that people build hardcore applications in languages where every method call carries the cost of reflection.
So does all this mean Hibernate is particularly suited to agile methodologies? Absolutely. Some agile methodologies (XP) came from more dynamic development environments like SmallTalk where the cost of refactoring was much lower than in a typical J2EE architecture. I could write an essay about why common J2EE (anti)patterns which encourage the growth of parallel class hierarchies (eg. Value Objects, DAO) are inconsistent with an agile approach - but this is not the place for that. Whats important is that this is a persistence mechanism that does not pose a barrier to frequent refactoring - and, in fact, grew out of our experience with combining J2EE and XP.
Why use get/set methods to access persistent fields? Why not go straight to instance variables? It decouples the implementation of your business object from its persistent representation. This is one of the best features of Hibernate. Your get/set pairs may be private if you like (or package, or protected), so this feature doesn't break data hiding. Since version 2.1 Hibernate supports direct field access, too.
Why doesn't Hibernate have a mapping GUI? Because you don't need one. The Hibernate mapping format was designed to be edited by hand; Hibernate mappings are both extremely terse and readable. Sometimes, particularly for casual / new users, GUI tools can be nice. But most of the time they slow you down. Arguably, the need for a special tool to edit mapping documents is a sign of a badly-designed mapping format. vi should be a perfectly sufficient tool. Instead of clunky GUIs, Hibernate offers XDoclet integration. You can, if you like, define mappings in Javadoc tags in the source of your persistent classes.
But what really makes Hibernate so good? It wasn't designed by a committee. Hibernate grew out of experience in an actual software project. It doesn't try to be all things to all geeks and so succeeds in doing one thing well.
|