Originally posted by don brown (aka brownie brownie):
firstly, VO and DTO are not the same.
The Data Transfer Object "DTO", is a simple serializable object used to transfer data across multiple layers of an application. The fields contained in the DTO are usually primitive types such as strings, boolean, etc. Other DTOs may be contained or aggregated in the DTO.
Posted by Stasko, Roger at that site:
There is a reason that the J2EE "Value Object" pattern was renamed to
"Data Transfer Object" pattern [that is what also I believed but what is not true. VO has been renamed to "Transfer Object", see below. Thomas].
A Money object as the typical example of the value object pattern -- an
instance of Money represents a particular immutable value. We make
value objects immutable to communicate what happens when the value is
changed (we get a new object so anybody holding a reference to the old
object are not affected by this change).
Posted by Kalra, Ashwani at that site:
... and other is j2ee pattern . later is now called DTO. As the
name implies, it is used to transfer data across different tiers in
coarse form to overcome the network calls.
... but unfortunately that link is broken.
Posted by: Raghu Kodali on November 23, 2004 ...
diff for Value object pattern vs DTO
Check out the following thread
... about "Composite Transfer Object Strategy sequence diagram":
The Transfer Object can be a simple object or a composite object that has subobjects (a graph), depending on the data requested by the client. The Transfer Object is serializable and it is passed by value to the client. The Transfer Object functions only as a data transfer object; it has no responsibility with respect to security, transaction, and business logic. The Transfer Object packages all information into one object, obtaining the information with one remote call rather than multiple remote calls. Once the client receives the Transfer Object, all further calls from the client to the Transfer Object are local to the client.
Name Collisions I've seen the term Value Object used for this pattern for quite some time. Sadly recently I've seen the J2EE community [Alur et al.] use the term "value object" to mean Data Transfer Object (401), which has caused a storm in the teacup of the patterns community. This is just one of those clashes that happen all the time in this business. Recently [Alur et al.] decided to use the term transfer object instead.
Originally posted by Thomas Taeger:
So finally we have VO = TO (and possibly = DTO - I don't care C#).
Remote Fa�ade and Session Fa�ade Over the last couple of years the Session Fa�ade [Alur et al.] has been appearing in the J2EE community. In my earlier drafts I considered the Remote Fa�ade to be the same pattern as the Session Fa�ade and used the Session Fa�ade name. In practice, however, there is a crucial difference. Remote Fa�ade is all about having a thin remote skin - hence my diatribe against domain logic in it. In contrast, most descriptions of the Session Fa�ade involve putting logic in it, usually of a workflow kind. A large part of this is due to the common approach of using J2EE session beans to wrap entity beans. Any coordination of entity beans has to be done by another object since they can't be re-entrant.
As a result I see the Session Fa�ade as putting several Transaction Scripts (110) in a remote interface. That's a reasonable approach, but it isn't the same thing as a Remote Fa�ade. Indeed, I would argue that, since the Session Fa�ade contains domain logic, it shouldn't be called a fa�ade at all!
Originally posted by Peer Reynders:
It's important for SCEA Part 2 to know the J2EE Patterns and document their use in your project � but as a technical professional you should aim to rise above the "nothing but Brand X" nonsense and prefer the use of the more general pattern language whenever possible � only use community specific patterns when appropriate or necessary � the idea is to communicate, not obfuscate.