Your application server’s CMP engine implements automated persistence. It takes care of the tedious details of JDBC ResultSet and PreparedStatement handling. So does Hibernate; indeed, Hibernate is a great deal more sophisticated in this respect. But Hibernate does this in a way that is transparent to your domain model.
We use transparent to mean a complete separation of concerns between the persistent classes of the domain model and the persistence logic itself, where the persistent classes are unaware of―and have no dependency to―the persistence
Mapping persistent classes
Our Item class, for example, will not have any code-level dependency to any Hibernate API. Furthermore:
Hibernate doesn’t require that any special superclasses or interfaces be inherited or implemented by persistent classes. Nor are any special classes used to implement properties or associations. Thus, transparent persistence improves code readability, as you’ll soon see.
Persistent classes may be reused outside the context of persistence, in unit tests or in the user interface (UI) tier, for example. Testability is a basic requirement for applications with rich domain models.
In a system with transparent persistence, objects aren’t aware of the underlying
data store; they need not even be aware that they are being persisted or retrieved. Persistence concerns are externalized to a generic persistence manager
interface ―in the case of Hibernate, the Session and Query interfaces.