Java Reference
In-Depth Information
•
Someone has to determine which bean field maps to which table column.
•
They require special method names. If these are not followed correctly, they will fail
silently.
•
Entity beans have to reside within a J2EE application server environment—they are
a heavyweight solution.
•
They cannot readily be extracted as “general purpose” components for other
applications.
•
They cannot be serializable.
•
They rarely exist as portable components to be dropped into a foreign application—
you generally have to roll your own EJB solution.
Hibernate As a Persistence Solution
Hibernate addresses a lot of these points, or alleviates some of the pain where it can't, so we'll
address the points in turn.
Hibernate does not require you to map one POJO to one table. A POJO can be constructed
out of a selection of table columns, or several POJOs can be persisted into a single table.
Hibernate directly supports inheritance relationships and the various other relationships
between classes.
Though there is some performance overhead while Hibernate starts up and processes its
configuration files, it is generally perceived as being a fast tool. This is very hard to quantify, and,
to some extent, the poor reputation of entity beans may have been earned less from their own
faults than from the mistakes of those designing and deploying such applications. As with all
performance questions, you should carry out tests rather than relying on anecdotal evidence.
In Hibernate it is possible, but not necessary, to specify the mappings at deployment
time. The EJB solution ensures portability of applications across environments, but the Hiber-
nate approach tends to reduce the pain of deploying an application to a new environment.
Hibernate persistence has no requirement for a J2EE application server or any other spe-
cial environment. It is, therefore, a much more suitable solution for stand-alone applications,
client-side application storage, and other environments in which a J2EE server is not immedi-
ately available.
Hibernate uses POJOs that can very easily and naturally be generalized for use in other
applications. There is no direct dependency upon the Hibernate libraries, so POJOs can be put
to any use that does not require persistence; or they can be persisted using any other “POJO-
friendly” mechanism.
Hibernate presents no problems when handling serializable POJOs.
There is a very large body of preexisting code. Any Java object capable of being persisted
to a database is a candidate for Hibernate persistence. Therefore, Hibernate is a natural
replacement for ad hoc solutions, or as the persistence engine for an application that has not
yet had database persistence incorporated into it. Furthermore, by choosing Hibernate per-
sistence, you are not tying yourself to any particular design decisions for the business objects
in your application.
Search WWH ::
Custom Search