Java Enterprise in a Nutshell, Third Edition

Principles of Hibernate

Often, programmers tend to skip introductory material and move right to the code. Sometimes we skip the code examples too and just pull up a seat at the keyboard and start hacking. Tempting as it may be to do so, plowing ahead without understanding the principles that Hibernate was built on is a dangerous thing to do. While persistence frameworks are meant to make life easier, they can be your worst nightmare if you don’t understand the principles that drive the framework.

Transparency

First and foremost, Hibernate strives to be a transparent service provider. When authoring an application, your customer derives value not from the choice of tools you use to create an implementation but from the domain model you create to solve his real-world problems. That domain model should be as testable, portable, and deployable as possible. Hibernate goes to great lengths to ensure that your application is as minimally dependent on it, its libraries, and its own dependencies as possible.

This means that the domain objects themselves are oblivious to the persistence mechanism you employ. They implement no interfaces, extend no base classes, refer to no APIs, nor even make any design concession to the Hibernate framework. The persistence logic and APIs are encapsulated away in the façade layer, allowing your domain objects to be truly domain-specific.

Reflection

Any ORM framework must provide a way to dynamically generate SQL CRUD (create, read, update, delete) statements ...