Java Transfer Object, what is it?

Question

Directly from this oracle article about the J2EE DAO Pattern:

Everything is very clear indeed but the Transfer Object "participant" (as they call it).

Here I quote the bit I would like more insights about (especially would be useful a real life example (an easy one)).

TransferObject

This represents a Transfer Object used as a data carrier. The DataAccessObject may use a Transfer Object to return data to the client. The DataAccessObject may also receive the data from the client in a Transfer Object to update the data in the data source.

I am trying to use this pattern as an exercise (as a student for the exam OCPJP it requires to understand the DAO Pattern). So far I have my DataSource (mysql database), my business object (JavaBean called Person) and my DAO object interfacing properly between the database and the JavaBean (Person).

So again What exactly a Transfer Object is?

EDIT: FROM THE FIRST REPLIES I UNDERSTOOD THAT ACTUALLY I KNOW WHAT A TRANFER OBJECT IS BUT I DO NOT KNOW WHAT A BUSINESS OBJECT IS... SO THE QUESTION REMAIN THE SAME BUT FOR THE BUSINESS OBJECT. NOT FOR THE TRANSFER OBJECT.

Thanks in advance and sorry about that.

Thanks in advance.

Answer 1

Transfer object is a simple class with fields and NO logic. They are serializable POJOs (Plain Old Java Objects) and have accessors (getters, setters) to access fields. They are called transfer because they are used to pass data between layers or roughly speaking group arguments to service method calls, they need not to match business objects.

Example

UserLogin { // just fields that are needed to login, not a User business object
    String name;
    String password;
}

LoginService { // sample sarvice that check passwords
    boolean Login(UserLogin userLogin) {...}
}

Transfer Objects are distinguished from other structure-like classes by the way they are used (transferring data) not by the way they are build (fields and accessors).

Answer 2

DTO

DTO does not have any behavior except for storage and retrieval of its own data (accessors and mutators). DTOs are simple objects that should not contain any business logic that would require testing.

DTO Usage

Case 1: Use DTO's if the domain object is huge, but you just need a few attributes of it! For large domain objects, in which the client visualize, change or display only a few of its attributes. In this case we recommend to use the notation: prefixDTO. This is the object which the client uses to do its works. The service gets the Domain Object, creates the DTO and gives it back. If this DTO is used in a wizard or kind of formular in which the user may type something in setting values, which means that you have to store the typed information into database, then you should use in addtion to the DTOs new objects called: prefixDTOData. why that? Because otherwise we would force the service which writes the attributes into database to iterate over the whole domain object (remember that the domain object is huge) looking and comparing for changes before writing down in the database.

Case 2: Use DTOs if the client has to show fields from different domain objects. In this special case you may consider putting all the needed attributes together already in the database creating the DTO in the server which is passed to the service going to the client. The client creates analoque to Case 1 a prefixDTOData an gives it back to the service. the reasons are the same as in explained in Case 1.