• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

SCEA 2/1 - Transfer Object Pattern question.

 
Steven Colley
Ranch Hand
Posts: 290
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI, What is the meaning of this statement regarding Transfer Object pattern ?

"Clients must access components in other tiers to retrieve and update data."

Tks!!!
 
giuseppe fanuzzi
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
transfer object is the mean for transporting data between tiers.
client can retrieve information because DAO layer loads data into transer object that business tier gives to client.
Viceversa, a client set transert object property and then gives it to the business layer
 
Steven Colley
Ranch Hand
Posts: 290
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes..ok!! tks!
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can find more on the transfer object pattern on Sun's site:

Understanding the Transfer Object Pattern

-Cameron McKenzie
 
Benoît de Chateauvieux
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Does the Transfer Object still have sense when JPA is used as persistence framework ?
Thanks,

Beno�t
 
giuseppe fanuzzi
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
of course!
Transfer object is the best vehicle when you've to move data between tiers.
An entity mapped with jpa is a business object, and it's not suggested to move business object between tiers
 
Benoît de Chateauvieux
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Giuseppe,

Thanks for your response.
Please, can you develop why it's not suggest to pass JPA entities to the view tier ?

For me, as they are POJO, you can
1- detach an entity from your Entity Manager and send him to your presentation tier.
2- The presentation tier modify this entity and send it back to the business tier.
3- The business tier merge it into the Entity Manager and update the DB.

Why using DTO in this case ?
Many thanks,

Beno�t
 
giuseppe fanuzzi
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The main reason so that a Business Objects POJO is not suggested to move between tiers is that it can be in a remote tier and can be wrapped in a session bean, and call remote methods cause network overhead.
And even if those POJO are not remote objects, you still should access them with a coarse-grained interface to send and receive data.
Moreover, do you know "application service" pattern? it uses pojo as entity objects only for "get" and "set" data from db and add another layer for real business functions.

Hope this help
 
Benoît de Chateauvieux
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Giuseppe,

What do you mean by "a Business Objects POJO [...] can be wrapped in a session bean" ?

For me, when actualized in the presentation tier, the entity will be passed as argument to a Session Bean's business method.
When the presentation tier is remote, sending a JPA entity or a DTO cause the same network traffic, doesn't it?

Thanks for your answer,

Beno�t
 
giuseppe fanuzzi
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if a client wants to call a remote business object, and if this object is not a remote ejb, then this client has to call a remote ejb (usually session bean) that calls the pojo business object.

so: client -> session bean -> pojoBO

the client, when calls session bean (usually by means of a business delegate), pass the transfer object to the session bean that, in turn, pass it to the pojo that does the work!

so:
in the client code: new businessDelegateSessionBean(tranferObject)
int the business delegate code: new sessionBean(transferObject)
in the session bean code: new pojoBO(transferObject)
in the pojoBO code: transferObject.getSomething()

Obviously "new sessionBean" supposes a ""
 
Gabriel Belingueres
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the DTO is a pre-EJB3 pattern, in that you will not want to call methods on an entity bean since this would imply that the entity bean need to be Remote. Instead, use always local entity beans and perform business logic through session beans and transfer the data (parameters and results) in DTOs. This way, if the presentation tier needs to access an entity bean instance data, you create a DTO class containing the same entity data, then you return a newly created DTO instance from the called session bean.

Now with EJB3 entity classes, this process of creating a DTO to transfer the exact data than the entity is unnecessary, unless of course you were calling a complex business method and need to return complex data then it is a good idea to create a DTO for this (but you can also create a Command pattern too)

See this post too for another opinion on this:
http://www.jroller.com/raghukodali/entry/dto_an_antipattern_in_ejb

Gabriel
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic