David Bullock wrote:

> The scheme of doing things 'coarsely' mentioned above is broadly referred to as 
>'pass by value'.  Pass-by-value always outperforms pass-by-(networked)-reference.  
>There were a couple of papers on the topic written by some of the EJB gurus on the 
>list, sometime last year, and they are at: 
>http://www.inprise.com/events/ejbdesign/submissions/Pass-by-Value.html
>
> In particular, the 'Pass by Value' paper by Richard Monson-Haefel is quite relevant 
>to what I discuss here.
>
> Richard also notes that your Serializable objects should be Immutable - ie. they 
>should only have public getter() methods.   I have been mucking around with 
>Immutable's and they make life a whole lot easier.   It helps if they implement 
>.equals() and hashCode() correctly too :-)  ... (it's really worth the effort!)

While I agree with everything else being recommended regarding coarse-grained entities 
and pass-by-value objects, I have never found it useful to require that my 
pass-by-value objects be atomic, dependent, fine-grained and immutable.

Regarding immutability, Richard says "PBV objects should be immutable so that they are 
not confused with remote references, which present a mutable interface. Because a PBV 
object is a copy, changes to its state would not be reflected on the server. Making 
PBV objects immutable avoids confusion."

I don't buy it.  I always have to know when I'm dealing with a copy or the original, 
regardless of whether the instance presents setters.  It doesn't confuse me or any of 
the programmers I work with, so why should I restrict myself this way?

Atomic: "An atomic object is one without a complex object graph. These objects have a 
very flat object graph with an emphasis on primitive properties over complex 
relationships with other objects. The reason is quite simple: the deeper the object 
graph the more work it is to stream the object across the network."

This presumes a slow, thin connection.  Maybe my application has tons of bandwidth to 
play with, and it would be really useful to stream complex object graphs to the 
client.  Maybe I have a custom serialization protocol that is super fast.

Fine-Grained: "Fine-grained objects have very limited scope and behavior. They 
represent granular business concepts that can not be easily deconstructed into small 
parts. PBV objects should be fine-grained because coarser-grained objects like entity 
or process objects should be represented by Entity and Session beans."

Dependent: "Dependent objects are those objects, which have little or no meaning 
outside the context of a particular business object. PBV objects should be dependent 
because non-dependent objects should be represented by Entity or Session beans. In 
other words, if the business object has meaning outside the context of another object 
it should be a bean not a simple object."

Why can't I have a coarse grained entity bean as a facade to a complex graph of domain 
objects, then stream that same graph of domain objects to the client, where local 
changes are made to the copy.  When the changes are ready to be committed, the 
modified complex graph can be streamed to a session bean, where the changes are passed 
on to the appropriate entity bean within the context of a transaction.  I have a high 
level concept, say "Customer", represented by
an entity bean and a complex, mutable, independent, coarse-grained object graph that I 
serialize and transmit to the client.  The client mutates the graph, then passes it 
back in the context of a transaction.  The mutations are made durable in the 
corresponding entity bean.

My $.02
begin:vcard
n:Wilson;Chip
tel;fax:(214) 358-0353
tel;work:(214) 642-4559
x-mozilla-html:TRUE
url:http://www.axyssolutions.com/
org:Axys Solutions
adr:;;;Dallas;TX;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Application Architect
note:Sun Certified Java Architect
x-mozilla-cpt:;-25088
fn:Chip Wilson
end:vcard

Reply via email to