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

Fri Mar 17 05:17:48 PST 2006

I would argue that perhaps validation IS business logic:

You add a new customer to your system, with an age of "F", your business
logic dictates that "an age of a customer must be a number" therefore
that is an invalid entry. You do not pass the new customer object to
your 'back-end', your database doesn't get a sniff and all of the
business logic has been applied in flash. You of course could replicate
that logic in the .net back-end and even in the database stored
procedure if you wanted to be ultra validated.

You would also probably have a customer object which will have certain
client side interactions which would be your business logic all applied
in flash.

Is that not applying business logic in flash? 

Dan

-----Original Message-----
From: Arp-bounces at ariaware.com [mailto:Arp-bounces at ariaware.com] On
Behalf Of Matt Brailsford
Sent: 17 March 2006 13:02
To: Arp at ariaware.com
Subject: Re: [Arp] The right way to use VO/TO's

So maybe i didn't explain what i meant quite rightly.

When i say business logic, i meant the business logic of the
application, not the components of how it is made up.

The way i work is that it is up to the .NET back end classes to do my
business logic such as, adding, removing, creating and making desisions
based on the data that was passed to it.

My flash front end is purley used to display the data passed to it, and
allow the user to enter new data into the system, which will be passed
back to the backend to process it.

My flash can do validation, and certain other actions on the data, but
as i said it is my back end that makes the business decisions.

I do use components, and i'm not disputing the fact they are technically
mini applications of there own. What i do mean is while they may have a
lot of functionality, then do not make any of my business desisions. 

A datagrid may allow columns to be sorted, inserted, and removed, fire
events when clicked on etc, but it doesn't know anything about what the
data means.

I'm not that great at explaining these consepts, but i hope this has
shed a little light on my point of view.

Matt

________________________________

From: "Chris Velevitch" <chris.velevitch at gmail.com>
Sent: 17 March 2006 07:33
To: "General List for Ariaware RIA Platform users and developers"
<Arp at ariaware.com>
Subject: Re: [Arp] The right way to use VO/TO's

On 3/17/06, Zoltan Csibi wrote:
> Chris...and why bother writing that email?
>
> Matt was talking about architecture, presentation layer as in

In an N-tier application, regardless of what the value of N is, Flash
is not the the presentation layer. Yes, we are talking about
architecture and the architecture creates the concept of the
presentation layer (views), Flash implements the presentation layer.
Flash also implements the rest of the architecture: controllers,
commands, service locator's, services, business delegates value
objects, model locator, etc.

> http://www.macromedia.com/devnet/flash/articles/flash_databases.html

This article is a bit dated as it refers to the capabilities of Flash 6.

Quoting from the ARP manual, page 1, paragraph 1:-

"One of the biggest problems facing Rich Internet Application (RIA)
developers today is how to architect their applications so that they
are maintainable, scalable and can be efficiently developed in a team
team-environment."

No matter thinly you slice the client tier of any N-tier client/server
application, you will be still be using a framework to architect that
tier. And then, via the framework, you'll layer the application in a
maintainable, scalable way. And one of those layers is the
presentation layer.

> "What is the backend anyway? Isn't it just a web-based
database?"...NO, IT
> IS NOT

Most N-tier applications interact with some persistent storage
mechanism. And given the delivery mechanism of Flash applications,
most, if not all, storage is web based. Granted, in a really large
N-tier (N>4) applications, some tiers are not database tiers, but tier
N is the client of a (N-1)-tier database application. In the end
there's a database of some sort somewhere on the web.

> "We're all building database applications using a client/server
> model"...We're all building less and less applications using a
client/server
> model and more applications using N-tiered architecture

All N-tiered applications are client/server applications.

> "Do you use any of the Flash components? What about all the business
logic
> bulitin to each component?"...What is the "business logic" built into
the
> components? What is "business logic"?

"business logic" is the way you want the application to work for a
given problem. Components are an "off-the-shelf" sub-applications.
Take the DataGrid. With a datagrid you can have user-driven column
sortings, cells can be editable or not, you render complex structures
in a cell, you can change the skin, etc. A DataGrid is a highly
complex application in its own right and is programmed by changing
specific attributes to make it solve your problem.

Even a 1-tier application is fractually an N-tier application.

Flash is a platform for developing/delivering applications, not a
presentation layer. The presentation layer is a concept in
architecture of an application.

I apologise, if I'm not clear about what I'm trying to say.

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

This message and any attachments should only be read by those persons to whom it is addressed and be used by them for its intended purpose.  It must not otherwise be reproduced, modified, distributed, published or actioned. If you have received this e-mail in error, please notify us immediately by telephone on 01202 237000 and delete it from your computer immediately. This e-mail address must not be passed to any third party or be used for any other purpose. Every reasonable precaution has been taken to ensure that this e-mail, including attachments, does not contain any viruses. However, no liability can be accepted for any damage sustained as a result of such viruses, and recipients are advised to carry out their own checks. 

Moov2 Ltd cannot accept liability for statements made which are clearly the senders own and not made on behalf of the Moov2 Ltd. An e-mail reply to this address may be subject to interception or monitoring for operational reasons or for lawful business purposes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ariaware.com/pipermail/arp_ariaware.com/attachments/20060317/ab2612d8/attachment-0001.htm