Re: Any knowledgeable Object -> Relational coders in here?

Hibernate looks *very* attractive. The trouble is how to get 'there'
from 'here', while protecting ourselves from this very same thing
again...

We were / are an EJB 2.X shop. We're sick to death of, ultimately, 4
different representations of our data:

Relational model in PG. We're happy with this layer. We maintain our
DDL by hand and have (relatively) clear visions on how to improve our
DDL, time permitting.

Entity bean model. We use XDoclet to generate our deployment
descriptors, so, ultimately, the entity container handles the runtime
relational <--> entity mapping. The Entity container caching we see as
good, for the most part. But, here's where we're really galled ...

DTO model. Can't use those wily Entities outside of the transaction,
so you gotta map 'em to plain-old objects, and we (currently) do this
by hand. This is done in our stateless session layer, with, ultimately,
hand-written code to transfer attributes to (in reader methods) DTOs
from Entities and from DTOs (containing just the subset of the data
graph which is necessary from said update view) to Entities for update
and create methods. Interspersed in the reading methods and the create
/ updating methods are little fairy dust sprinkles of actual business
logic, including row-level authorization checks. It seems that the
raw-data-movement code grossly outweighs the truly necessary
business-logic code, bloating the codebase and draining resources and
our souls in the process.

View models. Gotta render those DTOs into web pages and convert HTTP
GET / POST params into DTOs. Jython and Velocity (via JPublish.org) are
are apparent friends here.

OK -- Hibernate would allow us to eliminate the dichotomy between the
Entity (persistent object) model and the DTO model. Extremely cool.
We've already begun isolating 'knowledge' of Entity bean use to 'within
each package only', and each package interacting with other packages
only through the session interfaces, so that we could begin to migrate
from Entity beans to Hibernate or whatever other seemingly-better
persistent object model we deem suits our need best.

Questions, though:

Anyone take part of projects involving object persistence technology
upheaval have any tips to pass down?

How to code using Hibernate (or what have you) to prevent us from
having things be so painful the next time? EJB's CMR really seduced us
into establishing CMR between components in separate packages, and
we're going to have to work overtime in order to unravel those icky
bonds. But it is ultimately possible. But with Hibernate's seemingly
automatic traversal of an object graph at attachment time, is it
possible to relatively separate persistence logic across package
boundaries? With entity beans, our opinion of the transfer from
detached object to persistent object (in the form of the bodies of the
updating session bean methods) was that it is *too* explicit -- we
gotta write every line, whereas Hibernate might well be too automatic
-- the whole thing might run away on us when we reattach a single
composite object into the persistent graph.

Finally, somewhat related, some views need more data than others
(obviously), and some update pages update some data yet not others
(duh). When the data needed crosses architectural boundaries, we
ultimately end up returning too much information to the requesting
session-bean code / view code (which is subsequently ignored). If we
were coding in a fewer / no layered mode (i.e. JSP / PHP straight to
the database), this would not be an issue since we'd be coding explicit
selects with the appropriate joined tables / columns right in the view,
and we'd be good to go. But, as the number of layers increase, things
seem to ultimately err towards 'return more data to the view' as
opposed to 'add more fine-grained methods to the session layers'. Any
good patterns to reduce this, or do we just stink? If the data is
already cached in the entity layer, this isn't such a big deal, but
when the extraneous data read calls result in N+1 round-trips to the
database, it gets slow and annoying. And you can only cache so much
data... .

Ugh.

On Nov 22, 2004, at 12:20 PM, Dave Cramer wrote:

> Not exactly sure what you are looking for but have you looked at
> hibernate ?
>
> --dc--
----
James Robinson
Socialserve.com