Designing VOs
Is it right to make the vo reflect the screen? But if i set the VO independent of the screens I won't use all the data brought through the wire (wasting the bandwidth). What's the better way to solve this problem?
question 2: If I need to access a lot of data from a Bean including the data from the relationships (just some fields from this relationships), is it right to make a VO containing the tree of relationships? (wasting a lot of resources) I'll need just the description of those related entities.
Thanks in advance
Emerson Cargnin
> Is it right to make the vo reflect the screen ?
No.
A VO is a structural abstraction of the data.
A custom tag lib is more appropriate for a display/presentation centric abstraction of the data.
> But if i set the VO independent of the screens
> I won't use all the data brought through the wire
> (wasting the bandwidth).
De-coupling the VO from the presentation will not cause this, because that alone does not add fields, it sounds more likely that feature creep is responsible. Adding fields to the VO, because they may be useful. This is not necessarily a 'bad thing', it may add flexibility or extensibility, however you need to recognise it for what it is, feature creep.
Alternatively, you can always support a sparse collection of VO's, using Name-Value pairs. However in its own way this is also 'wasteful'.
I'm a firm believer that VO's should 'express' themselves. The specifics vary, but minimally this should mean supporting a toString().
I strongly oppose the idea that VO should be accessed by a bunch of aVO.getThis(), aVO.getThat() methods.
> What's the better way to solve this problem?
>
> question 2: If I need to access a lot of data from a
> Bean including the data from the relationships (just
> some fields from this relationships), is it right to
> make a VO containing the tree of relationships?
Yes, a VO that is a collection of other VO's is a good solution. It is quote common for to use the composite pattern to manage this.
So Customer VO may also contain Address(s) and Phone(s) objects
... aCustomer.aAddress.aTelephone.toString() ...
... aCustomer.aAddress.toString() ...
... aCustomer.toString() ...
