Reputation: 13108
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.
Upvotes: 3
Views: 13623
Reputation: 49221
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).
Upvotes: 6
Reputation: 68715
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.
Upvotes: 4
Reputation: 40338
It will transfer the data from one layer to another layer.You can call it as DTO(DATA TRANSFER OBJECT) or
VO(VALUE OBJECT)`.
For example if we fill a form contains user details to save in the databse.First values will go to the action class.Then i need to send it to the DAO through service.So in action class i will set all the details to a class and then access it in service class
Upvotes: 2