I have never found it useful to require that my pass-by-value objects be atomic, dependent, fine-grained and immutable. See http://www.inprise.com/events/ejbdesign/submissions/Pass-by-Value.html 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 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. The current project I'm on uses JSP pages and servlets to generate the user interface, so my "client" is in the same datacenter as my "server", and they are connected over a high speed network. Why can't my servlets and JSPs manipulate the same complex graphs of fine-grained domain objects that my EJBs manage? 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. Comments?
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
