Re: Java web application frameworks / architecture
Alessio Stalla wrote:
Wrt. Hibernate, I think it is a good library; however, starting from a
legacy DB you might have to design your entity classes in an awkward
way to adapt them to the database schema, and if the legacy schema is
sufficiently badly designed (as unfortunately is often the case) you
might be unable to exploit all the Hibernate features and have the bad
design reflected to your entity classes.
First of all, having a bad database design is a very serious problem
irrespective of whether you use Hibernate or another JPA product (OpenJPA,
TopLink/EclipseLink). In this it is like any bad design in your system - it's
going to hurt you. The pain is not linear with badness of design - it can be
quadratic or geometric. On one project some years ago my team lead forbade me
to normalize a relational database, thus requiring one report to run off of
and filter the unconstrained join between two very large tables. Nothing I
said convinced the team lead to let me normalize. ("I'm not changing the
database at this late date - find another way to optimize the report."
"Optimize". Sheesh.) When the report took days (or longer, who knows?) to
run with production-scale tables they finally normalized, but not until they'd
embarrassed themselves with their client. This was straight JDBC; we had no
3rd-party ORM layer.
Bad design gets reflected in your whole system, not just your entity classes.
That said, your entity classes do not have to match your tables one-to-one.
The idea isn't exactly to match entity classes to tables, it's to match entity
classes to the object model of the application. If you have the luxury to
design the database to support the system, you typically match tables to
entities, but you aren't matching entities to tables.
If the entities and tables do not match, that's where the mapping becomes
tricky but not usually impossible.
The biggest mistake people make with ORM packages is to use them to sustain a
data model in the program. This is ORM abuse. You use them to sustain an
object model in the program, and map it to a data model in the database.
I know from experience in large-scale projects that treating your entity layer
like a data layer can cause huge inefficiencies to emerge. If you use
entities as part of the object model, Hibernate (OpenJPA, TopLink) are usually
pretty good about caching and only hitting the database when they really need to.