Transfer Object Pattern

[Amandeep Singh]

What are the benefits of using the Transfer Object pattern? (Select two)


a The type of the actual data source can be specified at deployment time.
b The data clients are independent of the data source vendor API.
c It increases the performance of data-accessing routines.
d It allows the clients to access the data source through EJBs.
e It allows resource locking in an efficient way.
Answers: a and b


This question is from Hanumant Deskmukh Book...




Explanation
This pattern is used to decouple business logic from data access logic. It hides the
data access mechanism from the business objects so that the data source can be
changed easily and transparently to the business objects.




According to me the correct answers are b and c.

I have no idea why they told the answer a is correct. Any idea?

[Deepak Bala]

Option 'b' seems to be most appropriate.

Option 'c' need not be true. Option 'a' can be true even if you do not use value objects

[Amandeep Singh]

the type of data source is defined at the deployment time, but this is how useful for the transfer object pattern.

[Jimmy Clark]

The Tranfer Object design pattern and the Data Access Object design pattern are different. The code in a Transfer Object never connects to a data source. The purpose of the Transfer Object is for moving data around object-based components, i.e. tranfering data from one object-based layer to another.

This question and the answers do not address the purpose of the Transfer Object design pattern. It is no suprise that "correct" answers are confusing you.

The explanation above describes the Data Access Object design pattern, not the Transfer Object design pattern.
[ July 27, 2008: Message edited by: James Clark ]

[Amandeep Singh]

Thanks James, could you please explain from the prospective of the above answers that have been selected. it will be nice of you.

[Jimmy Clark]

Ok.

What are the benefits of using the Transfer Object pattern? (Select two)

a The type of the actual data source can be specified at deployment time.

The datasource is not related to a Transfer Object. The ability to specify the datasource type is not a benefit of the Transfer Object pattern, whether at deployment time or any other time.

b The data clients are independent of the data source vendor API.

Again, this answer does not make any sense since a Transfer Object has nothing to do with a datasource. This answer may make sense if the question was about the Data Access Object design pattern.

c It increases the performance of data-accessing routines.

This is not a benefit of the Transfer Object pattern

d It allows the clients to access the data source through EJBs.

Again, Transfer Objects have nothing to do with a datasource.

e It allows resource locking in an efficient way.

This is not a benefit of a Transfer Object implementation.


Hope this helps. To understand clearly, you need to understand the definitions and differences between the Data Access Object design pattern and the Transfer Object design pattern. The author of this question and answer seems to be missing this distinction.

[Bryan Basham]

James' answers are totally accurate. The author of that question appears to be confusing DAO with the TO pattern.

What no one has said yet is: What really is the TO pattern about. James mentions that TO is used for "transferring data from one object-based layer to another." This is correct but there is a deeper purpose. The primary purpose of TO is reduce network traffic between a remote business tier and the web tier.

If a remote business tier exposed an Entity EJB to the web tier, then every access method (getFirstName, getLastName, getAge, getGender, etc) would invoke a remote call to the business tier. The TO pattern reduces this traffic to one method call: getCustomerData():CustomerTO. This method, which is usually part of a remote Session bean (a'la Session Facade pattern), collects all of the customer data from the Customer Entity bean and packages it up into a Serializable object which is passed across the network in one transfer. Yes, this will be a bigger packet of data being transferred across the network, but the greater performance cost is the accumulative round-trip time of the multiple accessor calls describe above.

Hope that helps.

Note that the TO pattern is not needed if the web and business logical tiers are on the same physical machine (same JVM). In this situation, there is no network traffic when the web tier calls the individual accessor methods.

Regards,
Bryan

[Amandeep Singh]

Thank James, Bryan too. I already know Bryan is best. he is star, i want to follow your footprints, till right i dont know your footprints.