• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

A question on Value object or data transfer object

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When talking about J2EE design patterns, one frequently encounters the design pattern Value object /Data transfer object. And if you read a little more in this design pattern sometimes it says there are two copies of value object: one is on the server side and one is on the client side. Can someone say some words on this? What does this mean by saying two copy of value objects? Do you have some sample code to show? Thanks.
 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think what they mean is that the Value Object is just a serialized object that is passed to/from a client. Let's say I have a stateful session bean on the server that does:

...
private ValueObject myValueObject;

public ValueObject createValueObject()
{
myValueObject = new ValueObject();
return myValueObject;
}
...

Then when the client does:

ValueObject vo = bean.createValueObject();

you will end up with identical ValueObjects being on the client and the server. But, they are not the SAME object. Changes to one are not reflected in the other, that is why they are value objects. If you do vo.setName("NewName") for example, you only change the client version. To update the server you would need some sort of settor on the session bean. Like:

public void setValueObject(ValueObject vo)
{
myValueObject = vo;
}
 
Lynn Zhang
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you very much Brian, your explaination is really good. I however have a question on your sample code:

when client has a code in the following,
ValueObject vo = bean.createValueObject();

doesn't that mean that vo references the same memory allocated for the value object refered to by ( bean.createValueObject()), if this is true, your setting vo.setName("NewName") should also update the value of the value object in the sever side?

I know my understanding must be wrong, but just couldn't get myself clear on this.

Thanks.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi
What u get on a client is a copy of the Value object send to the client tru the wire by serialisatation.
and "bean" on the client is a remote reference
 
Lynn Zhang
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Small, What do you mean by saying client? Did you mean the browser? I thought the client mean the EJB client (Servlet for example). If client means EJB client, then this client should be in the same JVM as EJB and thus there is no need for wire transmission, right?
 
Brian Tinnel
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My reply was based on the assumption (possibly a bad one) that you were using a Remote interface. In that case, serialization should actually take place. If you are using a local interface, then I think you are correct that both server and client will see the same object.

That is one of the potential pitfalls people can encounter when changing a bean that is remote to one that is local. They might start seeing differences that were not there before.

If you had a local interface, then you might want to protect yourself by making a clone of the ValueObject before returning it. Another possibility would be to use interfaces and only expose getters. The setters would then be on the implementation side and only visible to the bean. I'm not sure what the best practice here is.
 
reply
    Bookmark Topic Watch Topic
  • New Topic