RE: "Uh, what do I need this for" (was RE: XML.COM: How I LearnedtoLove daBomb)

[Leigh Dodds <ldodds@ingenta.com>]

> -----Original Message-----
> From: Michael Brennan [mailto:Michael_Brennan@allegis.com]
> Sent: 22 August 2001 21:35
> To: 'Nicolas LEHUEN'
> Cc: 'xml-dev'
> Subject: "Uh, what do I need this for" (was RE: XML.COM: How I Learned
> toLove daBomb)

[...comments on EJB DAO layers...]

> You'll also notice in Sun's J2EE Blueprints white papers, they
> encourage the notion of "value objects" that can encapsulate the state of
an entity bean
> in a lightweight object that permits interaction with EJBs at a more
> coarse-grained level. These objects are just data.

We use a separate DAO layer and immutable Value objects, and they work
very well. One advantage of a separate Data Access Object layer is that
if you're writing a non-EJB oriented application (e.g. batch
update/processing)
that doesn't need to run in a full application server, you can reuse this
code. In this way Entity beans become adapters to plug your business
logic into the DAO layer.

One side effect of immutable Value objects I noted recently when
adding a SOAP interface to one of our components, was that I couldn't
take advantage of the Apache SOAP support for automated (de-)serialisation
of JavaBeans. Value objects aren't JavaBeans because everything is
done in the constructor, and there are no set methods.

No great loss, but it did mitigate one of the possible benefits of using
the Apache SOAP framework: I still had to write Serializers and
Deserializers
the same as I would have had to do with a custom XML messaging
format.

Cheers,

L.


--
Leigh Dodds, Research Group, ingenta | "Pluralitas non est ponenda
http://weblogs.userland.com/eclectic |    sine necessitate"
http://www.xml.com/pub/xmldeviant    |     -- William of Ockham