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

Subject says it all -- any experienced OO -> relational coders in here
willing to toss designs around in private?

----
James Robinson
Socialserve.com

Not exactly sure what you are looking for but have you looked at hibernate ?

--dc--

James Robinson wrote:

> Subject says it all -- any experienced OO -> relational coders in here
> willing to toss designs around in private?
>
> ----
> James Robinson
> Socialserve.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>
>

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561

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

On Monday 22 November 2004 13:05, James Robinson wrote:
> Ugh.

Indeed.

You may have better luck discussing this over at theserverside or some such.

This also may be of (long-term) interest to you:
http://java.sun.com/j2ee/letter/persistence.html

Vadim