I've sucessfully used a VO structure in a struts app and
used dot notation to access the data in just the way you
describe. However, in our case the VO's were immutable.
O.K., now for my 2c worth...
I'd be very careful using "generic" update methods like
updateVO() to process business logic. Say you have an
object with some state and you need to perform a state
transtion (A->B) you could do this by changing the state
value, or by calling a method that describes the state
transtion (i.e. startEngine()). If you simply change
the data, the "business logic" for allowable transitions
is in your client code... and the situation can only get
worse as more and more data values change. For example,
say a transition requires an associated date, now you need
to change two values in combination (see how the business
logic creeps down to your client) rather than using a method
(i.e. cancelOrder(Date cancelDate)). If you opt for an API
to encapsulate the business operations on your Entities then
you'll have a much cleaner interface, you'll be able to see
the business operations supported by the API and you'll
achive greater seperation of business/presenattion logic.
Some patterns to consider for this are Session Facade and
Business Delegate.
