aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes A question on Value object or data transfer object Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "A question on Value object or data transfer object" Watch "A question on Value object or data transfer object" New topic
Author

A question on Value object or data transfer object

Lynn Zhang
Greenhorn

Joined: Jun 04, 2004
Posts: 18
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.
Brian Tinnel
Ranch Hand

Joined: Aug 25, 2003
Posts: 69
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

Joined: Jun 04, 2004
Posts: 18
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.
small bull
Greenhorn

Joined: Aug 30, 2004
Posts: 1
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

Joined: Jun 04, 2004
Posts: 18
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

Joined: Aug 25, 2003
Posts: 69
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: A question on Value object or data transfer object
 
Similar Threads
B&S:concerned about overdoing DB implementations!
Are these patterns the same
Data Access Object & Value Object
Transfer Object Pattern
Part 2, Fast Lane Reader vs EntityBeans