LOL. Then you don't know what a VO is. I've done plenty of applications that function like a Flex app - and VO's are not needed, at least not how people normally define them. If you are talking about "projections" or "report objects" then I do use those (see hibernate documentation). But they don't contain anything more than convenience code.
Of course I do multi-tiered applications so there is no "middle tier" anymore. Business logic is needed to be performed in ALL layers. I do agree with your recommendation though - mostly. I have not used Flex enough, but UI specific code (formating/etc) in Java clients (SWT/Swing) is [correctly] handled with Renders/Providers. WinForms sadly doesn't have this. If you need keep your domain objects clean then use the decorator pattern. The VO/DTO pattern is majorly misused. Thankfully not so much in Java anymore as EJB3/ORM have taken hold. --- In [email protected], "Tim Hoff" <[EMAIL PROTECTED]> wrote: > > > Absolutely not true. Perhaps it wouldn't be a pure dto, but vo's often > contain properties that are only useful to the UI. Since you've chosen > to perform these calculations in the client, as opposed to the middle > tier; where business logic typically resides, each row of the collection > will have to be looped through anyway; either for precalculating > additional vo properties, or by using labelFunctions. Either way, those > are the recommendations. Good luck. > > -TH > > --- In [email protected], "mknuttall" <mknuttall@> wrote: > > > > Because then it wouldn't be a VO. :) > > > > --- In [email protected], "Tracy Spratt" tspratt@ wrote: > > > > > > If you are usign VOs, why not just add properties and have the VO do > the > > > calculation internally, and forget the labelFunctions entirely? > > > > > > Tracy > > > > > >
