Wednesday, January 2, 2013

Value Object vs. DTO


This subject is a controversial issue.
Check different sources below.

Reading the different definitions, I think that :

- Value Object are simple objects passed by value.

- DTO are tranfer objects, so serializable.

- Depending on the context, both may have same meaning, as referred by the J2EE documentation below, when a Transfer Object is passed by value or treated like so, but they do not represent the same concept.
 
- Summarizing:

  A DTO is linked to the concept of its pattern.
 
  A Transfer Object is an object that servers the purpose of a wrapped data transport object.
  So, it can be used in DTO pattern or anywhere else.
 
  A Value Object is a small simple object not based on identity, but on its values' equality.
   
    Depending on the context, things can assume the same role, so they seam similar on its purpose but not on their natures.


----------------------------------------------------------------------------------------------------------------------------------------------

Entity beans aren’t serializable.
We find that we must define additional data transfer objects (DTOs, also called value objects) when we need to transport data to a remote
client tier.
The use of fine-grained method calls (multiple method calls) from the client to a remote entity bean instance is not scalable.
DTOs provide a way of batching remote data access.
The DTO pattern results in the growth of parallel class hierarchies, where each entity of the domain model is represented as both an
entity bean and a DTO.

Use a Transfer Object to encapsulate the business data.
A single method call is used to send and retrieve the Transfer Object.
When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with
its attribute values, and pass it by value to the client.

Clients usually require more than one value from an enterprise bean.
To reduce the number of remote calls and to avoid the associated overhead, it is best to use Transfer Objects to transport the data from
the enterprise bean to its client.

When an enterprise bean uses a Transfer Object, the client makes a single remote method invocation to the enterprise bean to
request the Transfer Object instead of numerous remote method calls to get individual attribute values.
The enterprise bean then constructs a new Transfer Object instance, copies values into the object and returns it to the client.
The client receives the Transfer Object and can then invoke accessor (or getter) methods on the Transfer Object to get the individual
attribute values from the Transfer Object.
Or, the implementation of the Transfer Object may be such that it makes all attributes public.
Because the Transfer Object is passed by value to the client, all calls to the Transfer Object instance are local calls instead of remote
method invocations.


FROM:
http://java.sun.com/blueprints/corej2eepatterns/Pattern/TransferObject.html


  My Note: 
Within this context, it makes sense to assume Value Object as synonym to Transfer Object , because the Transfer Object is passed by value to the client.
Outside this context, a "Transfer Object" is not necessarily a "Value Object" cause instead of being passed by value it may contains references or representations.

Setback
If the Transfer Object comes like a big ship navigating up and down, other problems are raised - throughput (network traffic) and memory usages.
See Adam's comment, below on his blog.

----------------------------------------------------------------------------------------------------------------------------------------------
Data transfer object (DTO) is a design pattern used to transfer data between software application subsystems.
DTOs are often used in conjunction with data access objects to retrieve data from a database.

The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behavior except  for
storage and retrieval of its own data (accessors and mutators).

In a traditional EJB (Enterprise JavaBeans) architecture, DTOs serve dual purposes:

First, they work around the problem that entity beans  pre-ejb 3.0 are not serializable;

Second, they implicitly define an assembly phase where all data to be used by the view are fetched and  marshalled into the
DTOs before returning control to the presentation tier.

A third reason of using DTOs could be that  certain layers of the
application should not be able to access the underlying data access objects, and hence change the data.

A value object is a small simple object, like money or a date range, whose equality isn't based on identity.

FROM:
http://en.wikipedia.org/wiki/Data_transfer_object
http://en.wikipedia.org/wiki/Value_object

----------------------------------------------------------------------------------------------------------------------------------------------


A value object is a small simple object, like money or a date range, whose equality isn't based on identity.

FROM:  Wikipeadia


----------------------------------------------------------------------------------------------------------------------------------------------


The pattern which is known today as Data Transfer Object was mistakenly (see this definition) called Value Object in the first version of the Core
J2EE Patterns.
 

The name was corrected in the second edition of the Core J2EE Patterns book, but the name alue Objectbecame very popular and is still used as an
alias for the actual DTOs.
 

There is, however, a real difference between both patterns: A Data Transfer Object (DTO) is just as stupid data container which is used to transport
data between layers and tiers.
It mainly contains of attributes.
 

Actually you can even use public attributes without any getters / setters, but this will probably cause too much meetings and discussions :-).
 

DTOs are anemic in general and do not contain any business logic.
DTOs are often java.io.Serializable - its only needed if you are going to transfer the data across JVMs.
 

A Value Object [1,2] represents itself a fix set of data and is similar to a Java enum.
A Value Object doesn't have any identity, it is entirely identified by its value and is immutable.
A real world example would be Color.RED, Color.BLUE, SEX.FEMALE etc.

@FROM:
Adam's blog


No comments:

Post a Comment

eclipse: java: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" or Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder

  >PROBLEM Using Eclipse, you try to run a simple logging test using "org.slf4j.Logger" like the sample below: package Test; im...