Java, Software, Work

Transfer Objects versus Value Objects

What are Transfer Objects and what are Value Objects? This is a question that has plagued me since I started Enterprise Java Programming. While Transfer Objects actually have a nice definition in the J2EE Design Patterns Value Objects are a different beast and various companies, individuals and organisations seem to have different ideas about what they are.

Some are naturally pretty hilarious (as are the implementations of most nebulous ideas in IT) the most ridiculous so far is that a Value Object is a collection of public fields. Pretty much like a struct in C. I think that came from a misunderstanding of the blueprint definition that states: the members in the Transfer Object are defined as public, thus eliminating the need for get and set methods. Of course you still need to make the fields final if the object is to be immutable and a value object by definition is immutable.

Now though I feel I have enough of a working understand of the ideas to offer the following definitions.

Firstly a Value Object must be immutable, serializable and it’s content must be publicly accessible.  The content of a Value Object can be accessible via public final fields but to avoid the internal data becoming part of the public interface access should ideally be abstracted via getter methods. A value object should always be initialised entirely via its constructor; nesting value objects if necessary to avoid excessively long constructors.

A Value Object can only be changed and persisted by the creation of a new Value Object based on the values of the original Value Object obtained.

A Transfer Object while similar in most respects is mutable. In addition there is a reasonable expectation that the Transfer Object will be persisted if it is returned to the originating layer. So for example if a Session Bean provides a Transfer Object as the return value of one of its methods it is reasonable to expect the API to also provide a method that accepts an instance of the same Transfer Object. Any changes communicated to the Bean will be persisted and consistent so that if the original method that obtained the instance is called again it returns the values that have been returned to the layer and not the original object.

In this respect a Transfer Object is more the statement of expected behaviour on a Java Bean. I went to a talk about EJB3 where the speaker mentioned the detached object anti-pattern and I couldn’t agree more. Value Objects and Transfer Objects are really only useful in situations where the recipient layer is not really going to modify the objects that much. As soon as you allow POJO clones of entities to change value during a user transaction then you tend to get into all kinds of problems. It is exactly this kind of situation that ORMs and Hibernate clones tend to fall apart. They are great at obtaining Value Lists and dreadful at the kind of heavy lifting that is actually difficult and is where Entity Beans came a cropper in the first place.

Standard

6 thoughts on “Transfer Objects versus Value Objects

  1. Nallan says:

    Hey,

    Very clear explanation. One can get lost with a lot of jargons in J2EE and especially design patterns can get irritating to finally know that they are nothing but a set of best practices. For a first time reader without heavy experience using them, the definitions seem to be so much similar. In this context, your detail of explanation with comparisons and contrasts help a lot to gain that ‘practical experience’.

    Thanks a ton !!!

  2. Nav says:

    Hi

    Clear article, love it!

    Suppose if I retreive set of values from DB for a particular table I carry it till the UI (website), display (editable) and carry the value modified at the UI to persist in the DB

    Now, how can I use both TO and VO [OR] just one should be enough?

    need ur help…

    thx
    naveen

  3. Well since the data in the object is intended to be changed at the web layer you need to use a Transfer Object.

    There is a slightly more sophisticated pattern where you would generate a list of Value Objects for generating the view on the page and then when the user makes changes via the page generate an immutable List of Change Sets which are then actioned by the backend.

    That would minimise your communication and allow you to make or reject changes on a per change basis.

  4. hey
    nice article.
    I have some questions

    1. Value Object and Transfer object are 2 different core J2ee design patterns.
    2. both will be located at same layer.
    3. both objects resposibility is same? i.e, used to transfer data between layers

    Thanks for the valuable info.

    • Okay, so bear in mind these patterns of interaction are now very old and really more of historic interest. You really shouldn’t be using them now.

      A Transfer Object is used to transfer data between layers, a Value Object cannot transfer data between layers because it is immutable, it just displays the value to collaborators.

      The layer that can see the datastore offers these patterns as public items so other people can develop against them.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s