Appropriate use of value objects

[Peter Bergoff]

Hi everyone,

I know VO can be used to transfer data from the ejb layer to the web layer. Would the same VO be used to transfer data back to the ejb layer?

Also would it be appropriate to cache data in the VO to increase performance instead of immediately updating the persistent data? For example in a shopping cart app you would store the selected items in the shopping cart (i.e. VO) and not persist the data until the customer pays for the items in the shopping cart (i.e. send the VO data to the DAO).

[Ajith Kallambella]

I know VO can be used to transfer data from the ejb layer to the web layer. Would the same VO be used to transfer data back to the ejb layer?

Absolutely! Your clients can change the values and send the VO back to the application tier. Of course you will have to use some strategy( such a dirtyMarker) to figure out if the values have changed.

[QB]
Also would it be appropriate to cache data in the VO to increase performance instead of immediately updating the persistent data? For example in a shopping cart app you would store the selected items in the shopping cart (i.e. VO) and not persist the data until the customer pays for the items in the shopping cart (i.e. send the VO data to the DAO).

Exactly when you persist your data depends entirely on your requirements ie., in your example, does your usecase specify that the order cannot be placed until the payment has been processed or does it say customer pays only after the item has been located in stock and order fulfilment is guaranteed? - I hope you get the point.

I would be hesitant to treat value objects as data cache. In fact, no matter how well you design it, you will have to implement some sort of concurrency strategy to detect stale objects and prevent them from being persisted. Timestamping, vesioning etc are popular patterns. And don't forget that value objects are normally designed based on the client requirements and therefore may map to more than one business entity. For instance, ReservationSummaryVO might be made of attributes from Person, Flight, Reservation, and Payment entities.

Cheers,

[Harish Ramchandani]

I agree with Ajith.

I have another question in regards to VO names in Class Diagram and Sequence Diagram. In Class Diagram, we show VO as simple class name e.g. Itinerary. Can we refer same class as ItineraryVO in Sequence diagram?
In Mark Cade's book it is done for Order class. Any comments?

Thanks
- Harish

[Sanz Vai]

VO is a dumb object and normally doesn't contain any logic. If your Itinerary object contains logic to retrive objects like Segments, Flights, pricing etc, it cannot be regarded as VO as such. But of course, you can have an Itinerary as well ItineraryVO working as a data carrier only.

[Ip Patrick]

Hi,

In practical environment, sometimes I find it difficult to reuse the same VO to get data from server to client, modify it and pass it back to server. It is because the server-to-client object contains many browse information while the client-to-server object should only contain information about users' selection. The fields to be transferred are quite different. In this case, we are forced to use different VO, right?