Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Transfer Object, HFS p823 Q44

 
Roger Yates
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In what way does a Transfer Object help to reduce duplicate code?
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think TO aims to allow data being passed from backend to the frontend.

In old days (in fact, maybe just 1-2 years), it is named as Value Object.

I am not sure whether using it can save coding effort, but you definitely can transmit data with an easier way.

Nick
 
Chengwei Lee
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of the benefits of TO is that it reduces network traffic. You pack all the related stuffs into a POJO & send it across the network. Beats using entity beans in terms of performance.

Also, it could be a lightweight representation of the table, since some JSP don't really the display of all column values. You could gather values from a few tables into the POJO & maybe thats why the code saving come in? Instead of having a single POJO for each table?
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

why the code saving come in?

One saving I can think of is, we dont need to *process* the result in the raw format.

For example, in order to get an account, you can either:
public Account getAccount(); OR
public Object[] getAccount();

If we use the 2nd way, which not using a TO, we need to write codes, say, for identifying which position is what item (like balance, number, etc), but if we use the 1st way, which is a TO, we can then use getBalance(), getNumber(), etc to get the data.

In such sense, code is really save for parsing the result, but NOT the processing of server or DB side.

Nick
 
Bert Bates
author
Sheriff
Posts: 8905
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another thing to keep in mind is that using the TO simplifies the remote object and the remote interface.
 
Roger Yates
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm. Thanks one and all,
Food for thought...

Remote interface and remote object are simplified - this is good. But then you have to create more code (TO) to allow this to be simplified.
I think the "feature" of "should reduce code duplication" is misleading and should be removed from the question.

I've looked in J2EE patterns for references to code duplication for the TO pattern, and the only reference is due to the creation of the TO anyway. Here's the ref I think may have resulted in the inclusion of this 'feature' in Q44:

Entity Inherits Transfer Object Strategy
...this strategy eliminates code duplication between the entity and the Transfer Object


i.e. If you hadn't used TO, you would have this duplicate code to reduce!

I'd have picked TO as my answer were it not for the "should reduce duplicate code" feature. The only option I could see that ought to reduce duplicate code was Service Locator, but this didn't fit the others. In the end I thought maybe Business Delegate, in conjunction with Service Locator and TO! But this wasn't the answer!!!

This questions was one of the scoundrels that shrunk my score to 52/69 for the Mock!

Wish me luck, I've got 2 hours to go before my SCWCD cert...
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roger,

I see what you mean.

Anyway, best luck to your exam, and tell us good news about that!

Nick
 
somkiat puisungnoen
Ranch Hand
Posts: 1312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
TO is reduce overhead of remote call method and is large-grained object.
 
Bryan Basham
author
Ranch Hand
Posts: 199
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

The TO pattern is primarily about reducing network traffic, by moving all of the data in an entity over the network (from the business tier to the web tier) in one remote call rather than multiple remote calls (one for each data attribute).

The TO pattern does not reduce duplicate code as HFS says. That is a mistake.
Sorry for the confusion.

BTW, the new JDK v1.5 (Tiger) feature of annotations/metadata *might* be used to automate the creation of TO classes from your Entity bean source code. Please don't ask me how, because I don't know. But this is the type of hype that I'm hearing about the annotations feature.

-Bryan
[ October 22, 2004: Message edited by: Bryan Basham ]
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the clarification.

There will be one more errata added.

Nick
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

BTW, the new JDK v1.5 (Tiger) feature of annotations/metadata *might* be used to automate the creation of TO classes from your Entity bean source code. Please don't ask me how, because I don't know. But this is the type of hype that I'm hearing about the annotations feature.

But this feature would not appear currently, rite?

As J2EE 1.4 (EJB 2.1) is currently in J2SE 1.4. In order to adopt Tiger, I guess it would be at least in J2EE Tiger (EJB 3.0).

Also, since EJB 3.0 using POJO for EJB objects, this can then be possible, isnt it? If we use the old way (EJB 2.x), auto creation seems impossible.

Nick
 
Roger Yates
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bryan,

Thanks for clearing that up.
I've paid a visit to my favourite page
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic