Not pretending to be guru...
Yes there are two trees with very similar code, but I do not write this code. I even do not write bean classes. I have templates, which describe hierarchy, attributes, finders, "extra" methods, DB mapping and other stuff -- all in one file. Then the file is processed and I get my beans. Then XDoclet does the rest (well, most of it). And I still like VO, since it protects from users calling get/set on remote interface "needlessly".
From: "Ara Abrahamian" <[EMAIL PROTECTED]>
To: "'Hicks, James'" <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]>
Subject: RE: [Xdoclet-user] attributes in data object
Date: Fri, 19 Apr 2002 16:58:07 +0430
> "What I am trying to do is allow lazy-loading of related objects from
data
> object. So it contains some finder-related methods, which go and fetch
the
> data."
>=20
> I like this idea: lazy loading Aggregated/Composed ValueObjects from
> ValueObject. Maybe have the ValueObject use the aggregated/composed
beans
> util object to do a lookup and retrieve the value object? Could solve
the
> problem of large data graphs, but at the cost of multiple network
trips.
I don't like this idea! You're ending up writing two set of more or less
similar code, one in value object and another in your ejbs. Honestly I'm
starting to hate this valueobject pattern! In my application I ended up
modeling everything (the graph I mean) as serializable dependent objects
and simply pass them around. All ejb container dependent code is out of
those dependent objects, inside a session fa=E7ade. And btw if web and =
ejb
tiers on in the same jvm you don't really need value object, just wrap
the access in a transaction.
Imho it really is a design discussion, and by the above design I don't
have to deal with value objects any more, I only use a finer grained one
for listing.
I'll be glad to hear what ejb gurus think. Comments?
Ara.
