Value Object (VO) vs. Transfer Object (TO) vs. Data Transfer Object (DTO)

[Thomas Taeger]

Hello Don,
hello all,
... now to the unintended and unexpected second sub-discussion: DTO vs. TO vs. VO:

Originally posted by don brown (aka brownie brownie):
firstly, VO and DTO are not the same.

When you compare todays "Core J2EE Patterns: Patterns index page" at
http://java.sun.com/blueprints/corej2eepatterns/Patterns/
to "Figure 6.2 J2EE patterns relationships" on page 141 of the older book Deepak Alur et al. "Core J2EE Patterns"
then you find exactly two differences:
- "Value Object" of the book is called "Transfer Object" (not Data Transfer Object, ok) now
- "Value Object Assembler" of the book is called "Transfer Object Assembler" now.
But todays comment on the edge from Session Facade to Transfer Object Assembler still is
- "Obtain Composite Value Objects".

So first off all I must apologize to Saha who used TO (Transfer Object) naming correctly.

For clarifying if there could be any difference between
- "Transfer Object" and
- "Data Transfer Object" (and their Assemblers respectively).

I found on (a C# site) http://www.codeproject.com/csharp/datatransferobject.asp:

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.

http://archives.java.sun.com/cgi-bin/wa?A2=ind0308&L=j2eepatterns-interest&P=8988

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.

So we have VO = TO = DTO for the first step.

At: "www2.theserverside.com/discussions/...":

Posted by: Raghu Kodali on November 23, 2004 ...
diff for Value object pattern vs DTO
Check out the following thread
http://www.patternscentral.com/modules.php?name=Forums&file=viewtopic&t=78

... but unfortunately that link is broken.


By java.sun.com > Search "Data Transfer Object":
At http://java.sun.com/blueprints/corej2eepatterns/Patterns/CompositeEntity.html

... 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.

Because data transfer object is not written having capitals I believe "Data Transfer Object" is really the C# name for what J2EE calles "Transfer Object" today and called "Value Object" before -
without any intent to discuss C#-specifica of DTO here.

So finally we have VO = TO (and possibly = DTO - I don't care C#).

Who does not agree: Please provide an official source / site authorized for naming these patterns.

Thomas
[ May 10, 2006: Message edited by: Thomas Taeger ]

[Peer Reynders]

The use of the terms is not consistent over time and between communities (i.e. beyond Java EE).

Patterns of Enterprise Application Architecture (amazon)
Value object
Page. 487

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#).

Sorry, but you should care. DTO is the name that the general pattern community (i.e. not Microsoft specifically) will use for the Java EE TO. And there is no point in using VO in the former J2EE meaning because it's just going to confuse people (as your posts demonstrate) - just use the TO moniker.
Some of the Java EE patterns have no equivalent in the general pattern community (e.g. Composite Entity) because they address peculiarities that are only found in Java EE architecture. Then you have the Java EE DAO, which the general pattern community finds a bit too vague � they have three patterns that could fit: Table Data Gateway, Row Data Gateway, and Data Mapper.

Another Example (p.391):

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!

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.
[ May 10, 2006: Message edited by: Peer Reynders ]

[Thomas Taeger]

Hello Peer,

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.

thank you very much for your recommondations!

It is true, outside the GoF and for instance the J2EE patterns I feel like a novice.

Allthough respecting the topic of this forum being J2ee specific:
- Can you help me with links giving an overview and/or a clear definition of "non-brand"-patterns of "the community"?
- What is this community? Anywhere located? Driven by whome or what? ...
- Especially links that could pick me up with my GoF and J2EE pattern know how compared to "common" patterns would be helpfull.

For instance the terms "DTO", "TO" and "VO" I would like to clarify for myself.

Thank you in advance,
Thomas

[Peer Reynders]

In general the J2EE Community has managed to establish their own set of patterns mainly to deal with problems that tend to arise in the J2EE environment. Some overlap was unavoidable. And as the DAO and "Remote Fa�ade vs Session Fa�ade" demonstrate there rarely is a perfect one-to-one relationship. The "DTO vs TO" is the exception and "Value Object vs VO" is just plain unfortunate.

Some J2EE patterns do not translate to non-J2EE environments � however general patterns are useful in Java and Java EE to solve some recurring design challenges. Sometimes Core J2EE Patterns will reference general patterns (see for example: Application Controller)

The baseline for J2EE patterns is established by:

Core J2EE Patterns 2e

EJB Patterns (PDF)

J2EE AntiPatterns

The baseline for general design/patterns is established by:

Design Patterns: Elements of Reusable Object-Oriented Software (GoF)

Pattern-Oriented Software Architecture � A System of Patterns Volume 1 (POSA1)

Smalltalk Best Practice Patterns

Pattern Languages of Program Design

Pattern Languages of Program Design 2

Pattern Languages of Program Design 3

Patterns of Enterprise Application Architecture (PEAA)

Domain Driven Design � Tackling Complexity in the Heart of Software (more design � not really patterns)

AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis

[Jeanne Boyarsky]

karthik chitrothu,
Your post was moved to a new topic.