Skip site navigation (1) Skip section navigation (2)

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

From: James Robinson <jlrobins(at)socialserve(dot)com>
To: pg(at)fastcrypt(dot)com
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Any knowledgeable Object -> Relational coders in here?
Date: 2004-11-22 18:05:32
Message-ID: 1995360A-3CB1-11D9-9AEC-000A9566A412@socialserve.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
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


In response to

Responses

pgsql-jdbc by date

Next:From: Vadim NasardinovDate: 2004-11-22 18:24:23
Subject: Re: Any knowledgeable Object -> Relational coders in here?
Previous:From: Nicolas ModrzykDate: 2004-11-22 17:48:52
Subject: Re: [c-jdbc] Bug Report

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group