ManifestoHibernate is designed to support the combination of J2EE and agile methodologies. If your development process fosters (and relies upon) rapid change, it is important to use technology that makes change inexpensive. When refactoring is expensive and hasslesome, your agile development process is more likely to produce entropy than malleable software. CMP Entity Beans is an example of a technology that makes refactoring expensive. Without proper support for fine-granularity collections and dependent objects, you are forced to choose between coarse-granularity CMP beans and hand-coded JDBC. Neither solution is well adapted to rapid change. The first solution limits code re-use. Patterns supporting the second solution (like DAO) encourage the growth of parallel class hierarchies. Hibernate is a persistence solution for old-time OO purists and people who believe that business objects should express the business model in the cleanest, most idiomatic Java possible. XP, for example, grew out of the SmallTalk community. Hibernate is modelled upon the kind of persistence solutions used in that environment. By contrast, most other Java solutions - using code generation or bytecode processing - are modelled on solutions from C++. Java has much in common with C++ but even more in common with SmallTalk; particularly its support for runtime reflection. Hibernate is ultra-vendor neutral. The runtime engine is compatible with eleven open source and commercial databases and should be out-of-the-box compatible with some other databases. The schema generation tool requires about an hour or two of work to support each new RDBMS. So even if your database is not yet officially supported, you will probably still be able to use Hibernate. Hibernate is scalable. The architecture is designed for very high thread-level concurrency. You can even use it in a cluster. On the other hand, it has a small footprint, so it even scales down. Hibernate can go places your application server can never go.
|