> > "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." > > > > 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!
I do also :) But because VO creation is no more a problem with xdoclet... I don't know > 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�ade. ...and the session facade decompose/compose the dependant object and call the entity beans ? That is the Value Object afaik except that the entity itselef is handling them, for you it is a session facade. ??? > 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. You mean having entity's fields getter in the local interface ? You still have the security/... that the container do on ejb acess Overhead no ? > > 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. > Vincent _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
