Transparent and automated persistence 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 mechanism.
Mapping persistent classes Our Item class, for example, will not have any code-level dependency to any Hibernate API. Furthermore: 1、 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. 2、 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. 3、 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. Hibernate的这几点，正是EJB值得借鉴的地方，EJB的规范太复杂了。
All these frameworks seem like silver bullets and this is evidenced by the fact that none of them seem to have much staying power. The ironic thing is that instead of decreasing accidental complexity, they seem to increase it. (I never needed all these XML files, complex IDEs, and ORM tools before) It's funny that you don't hear much discussion about good design anymore ever since EJB's popped up. Developers seemed to be enamored with the paint-by-numbers approach towards design that these architectures seem to promise. However, once you have to step outside of their box you find that rather than helping you, they get in your way. All I seem to hear about nowadays are new languages, IDE's, tools, etc that are supposed to make coding easier. What happened to good design? It's amazing that a whole sub-industry has popped up to just replace the layer that places data in an HTML page and the layer that gets data from the database. It's not that hard. You're moving a value from one place to another. It doesn't require a new paradigm or a tool set beyond JSP's, Servlets, and JDBC. These are simple tools that do the job and they're appropriately simple for the simple problem they solve. I've found they only suck when people can't design properly, but no tool is going to fix that.