Adam Bien's Weblog

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:

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.

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

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.

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.

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.

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

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.

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.