[Arp] The right way to use VO/TO's

[Matt Brailsford]

Hi Chris,

Thanks for getting things back on track.

You have explained an interesting example, and i can see why you have 
chosen to put some business logic within the view.

I myself would see this as validation, as your application isn't making 
any decisions upon the data, all it is doing is formating the data in 
such a way that the business layer requires it, no?

With respects to data transfer, would you pass back the VO with the 
business logic back to the server, or did you create a seperate VO with 
only the information your back end requires?

Many thanks

Matt


Chris Velevitch wrote:
> On 3/18/06, Davies, Grant M. <grant.davies at nscorp.com> wrote:
>   
>> Ok so maybe we can gear this back on topic and get chris to explain a
>> typical architecture of one of his applications
>>     
>
> Very diplomatically put.
>
>   
>>                                                        , with specific focus on data
>> objects and whether his data objects are VO's or a more detailed object with
>> business logic, and using VO's purely for transfer?
>>     
>
> When I first started using ARP, there was no ModelLocator, so my model
> was basically a set of VOs that I had to actively pass around my
> application. As for business logic some of my VOs do have some rules
> like an timesheet dayVO to store the start and end times and the
> length of all breaks. So I have a getter to return the time actually
> works. The same goes for my weekVO, in that I have a getter to return
> the time actually worked for the week.
>
> I also have some fairly elaborate business logic in the my
> TimesheetEntryForm. 1) I have a time entry mask so you can only enter
> a valid 24 hour time. Any key stroke that is not valid for the current
> position in the time is silently ignored ie not displayed. 2) if you
> have entered a start time, then any time value before the start time
> is ignored. Similarly for the start time. 3) the actual time worked is
> automatically computed on each key stroke. This is guaranteed to never
> be negative or invalid due to 1 & 2 above. 4) break time is never
> allowed to be more than the end-start time. It's automatically reset
> to be end-start time. Help to ensure 3 above. 5) time-and-a-half can
> never be more than the actual time worked and is automatically set to
> the actual time on each key stroke. 6) double time can never be more
> than the actual time-time-and-a-half. It is automatically set to
> actual time less time-and-a-half on each key stroke. 7) if changes in
> start, end or break times causes 5 or 6 to be violated, 5 and 6 are
> automatically reapplied. 8) the total actual time, total
> time-and-a-half and total double time are automatically calculated on
> each key stroke.
>
> You may say this is all input validation, but you'd be wrong. It's the
> nature of the beast that implies all this business logic.
>
> Why is it being done here in the view? So then the user presses the
> save button, they know they're done. No niggling little annoying alert
> boxes popping up to call them back to fix any problems they made. The
> people using this application will be using this once a week, at the
> end of their day and they want to make sure they get paid and they
> want to go home.
>
> Unfortunately this is my first and only ARP (and Flash) based
> application and the rest of the application is much the same. The
> business logic is in the view, with business rules in the database as
> fallback.
>
> I don't have the code handy, but thinking about what I've just
> written, how I have structured the TimesheetEntryForm, not very MVC
> although the overall architecture of the program is,
>
>
> Chris
> --
> Chris Velevitch
> Manager - Sydney Flash Platform Developers Group
> www.flashdev.org.au
>
> _______________________________________________
> Arp mailing list
> Arp at ariaware.com
> http://ariaware.com/mailman/listinfo/arp_ariaware.com
>
>