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

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 "Value Object" became very popular and is still used as an alias for the actual DTOs. There is, however, a real difference between both patterns:

  1. 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 - its only needed if you are going to transfer the data across JVMs.
  2. 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.

Data Transfer Objects are widely overused and the "real" Value Objects a bit unattended. Most developers who use the term Value Object actually have in mind DTOs. I have to continuously correct myself as well :-).

See also: How Evil Are Actually DTOs?

[See Data Transfer Object, page 153 in "Real World Java EE Patterns Rethinking Best Practices" book


what about @Embeddable?

I also name an @Embeddable as ValueObject (not only Enums).

Embeddables dont have an own database-identity, so for me they are ValueObjects ;-)

Do you think the term ValueObject is wrong used for @Embeddables ?


Posted by ekke on August 19, 2009 at 11:48 AM CEST #

Value Objects are a core concept in Domain Driven Design (DDD).

If you are searching in this context, there are a lot of discussions:

I also think that @Embeddable (components in Hibernate) is the ORM-constructs that is very closely related to Value Objects.

Posted by Jonas Bandi on August 19, 2009 at 01:05 PM CEST #

I don't think that you can compare @Embeddable with Value Objects.

@Embeddable is used to split one database table into two (or more) classes.
It's the opposite of @SecondaryTable

Posted by Simon Martinelli on August 19, 2009 at 01:59 PM CEST #

if using an @Embeddable Class for per ex. GPSCoordinates then I can embed this in many different @Entity Classes.

so from my POV its a ValueObject without (Database)Identity

how this will be mapped to database tables is another story.

Posted by ekke on August 19, 2009 at 02:38 PM CEST #

I support ekkes POV.

One of the main characteristics of a Value Object is, that it does not have its own identity. (The identity concept in this context is not directly related to DB-Identiy).

By using @Embeddable we define exactly this characteristic.

@Embeddable (and also @Entity) has additional semantics for our domain-model that goes beyond how to map classes to tables.
These semantics are not expressed in the unannotated class model. But these semantics express concerns that are not only related to persistence.

Posted by Jonas Bandi on August 19, 2009 at 03:38 PM CEST #


An @Embeddable can be be a Value Object, but don't have to.
But: GPSCoordinates sound very like a Value Object. All instances with the same value are the same and you are only interested in the value and not the reference.

Thank you for your comment!,


Posted by Adam Bien on August 19, 2009 at 03:40 PM CEST #

And how do you call objects used as Hibernate entities then? Because a lot of people are referring to those non-anemic entity POJOs as value objects. And for me the problem is that they even use those as DTO's most of the time. But DTO's are like you said, data containers with almost no business logic in them, except maybe some validation constraints.

Now I totally disagree with you that those DTO's are only needed when you transfer data between 2 JVM's. Not only are they increasingly useful when you use client-side RIA things like GWT or Flex (to avoid LazyInitializationException's and such), but from a design point of view, they also allow you to isolate your storage model from your business model in order to expose only the data that needs to be (good for security, maintainability and performance). Of course it costs a little bit of mapping code, but IMHO it's a very low price to pay.

Posted by Sébastien Arbogast on August 19, 2009 at 04:47 PM CEST #


I meant: you only need DTOs which implement if you are going to transport the data across JVMs. Otherwise you can just use DTOs without implementing the,



Posted by Adam Bien on August 19, 2009 at 05:00 PM CEST #

@Sébastien, what Adam said was that DTOs contain no (zero, zilch) business logic. That was the original concept. They were to get data across the network efficiently. It was not even JVM to JVM. It was not because of layers. It was an network efficiency issue. But that was because EJBs. But when using POJOs, you don't have this issue anymore.

But as you mentioned, there is another issue when you cross technologies. People have taken the DTO concept and used it for another reason. At this point, they are not really DTOs anymore. The DTO pattern was to extract the attributes on one side of the network and recreate the object using the DTO on the otherside. Thus there was no need for business logic. The Domain/Entity object was used on both sides.

The problem is that, no matter how good we make them, Flex and AJAX(clientside like GWT) are not a good fit for Java/C# on the backside. And what most people are calling DTOs are not. I don't know what to call them except maybe mutant objects because people put business logic in them. You can use technologies like Gilead instead of using the DTO anti-pattern. Having to resort to DTOs is a sign of a problem. It was in EJBs and it is now.

As for what other people are doing with Hibernate (basically POJOS) well that is because most people are not that good at OOP. Don't take bad programming as a sign of anything else but that. It is not a license for anyone else to ignore good principles.

As for "isolat[ing] your storage model from your business model". There is no such thing. Unless you mean the database. If so, it is. Take a second to read "Domain Driven Design Quickly" and then check out Spring (especially Spring security).

And No, I am not saying that you should not use "Report Objects" or "Projections". Basically these are "read only" objects that allow you to select multiple attributes from 1 or more objects from the persistence store so you don't have to load the object into memory until you are ready to work with it.

Posted by Mark on August 20, 2009 at 04:33 AM CEST #

Excellent information. Thanks for this! I suggest you add image to show clearer difference. Regards!

Posted by John Ortiz on July 13, 2010 at 08:59 PM CEST #

Surprised and an eye opener!!
Need to study more on this.


Posted by Priya on November 16, 2010 at 06:01 PM CET #

Aren't DTOs immutable? I don't see any difference between DTOs and VOs they are just immutable data structures

Posted by Mahesh on February 17, 2011 at 07:29 AM CET #

I used to think both are one and the same. The post educated me.


Posted by Java Coder on June 18, 2011 at 11:06 PM CEST #

And ...vs beans?

Posted by s2o on July 13, 2011 at 07:20 PM CEST #

Your comments are not correct. DTO's are just what the name implied. The Java EE patterns are also correct. You are trying to apply Domain Driven Design language to patterns that predated the first book on the subject.
The J2ee design patterns knew nothing of the Domain Driven Design and the patterns should not be enveloped by DDD preachers to advocate there ideas.
In DDD a Value Object is an Object without Identity. That is not the same as the Java EE pattern.
They don't have to be. This allows for a Domain expert to not have to know Java EE patterns to describe there domain.
It is unfortunate that Eric Evens utilized common patterns names in creating DDD. This has left many developers thinking that an Entity is an ORM Entity.
In DDD an Entity is a Java EE Value Object with identity.
So please stop trying to merge the patterns. They may use the same names but they correspond to completely different concepts.

Posted by Chris Martens on September 24, 2011 at 06:29 PM CEST #

i have saticefied with the information provided for this question.

Posted by Ramakrishna Muddana on June 05, 2012 at 07:09 PM CEST #

DTO implements serializable(I).Serializable objects are always immutable.Thats the speciality of DTO.

Posted by raju on July 14, 2012 at 05:51 PM CEST #

I understand from above discussion that DTO could be more useful in distributed systems where we have to transfer data across service boundaries but I am not sure if Value Object is really a significant pattern. Enums, Constants in static class could be categorised as Value Objects.

Posted by Pravin on May 19, 2014 at 07:33 AM CEST #


DTO: "Data transfer objects " can travel between seperate layers in software architecture.

VO: "Value objects " hold a object such as Integer,Money etc.

POJO: Plain Old Java Object which is not a special object.

Java Beans: requires a Java Class to be serializable, have a no-arg constructor and a getter and setter for each field.

Posted by Snehal Masne on August 06, 2014 at 01:58 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments