[Arp] Best practise: no VO's server side?

[Davies, Grant M.]

Oops, grammar error.
 
Also added a sentence at the end.
 
 
 
-----Original Message-----
From: Arp-bounces at ariaware.com [mailto:Arp-bounces at ariaware.com] On Behalf
Of Davies, Grant M.
Sent: Thursday, January 26, 2006 12:09 PM
To: 'General List for Ariaware RIA Platform users and developers'
Subject: Re: [Arp] Best practise: no VO's server side?
 
Ah I get you.
 
It's a bad design practice not use VO's in a service based architecture
which is what ARP talking to fluorine or whatever would be.  The same goes
when using web services.
 
When you use "normal" methods you are often using objects that incorporate
behavior which may or may not be duplicated on the client side.  Early 3
tiered architectures available to java and .net like CORBA often did not use
value objects with very poor results.
 
When you don't use value objects you often do more fine grained calls which
puts more burden on the network and on the server and tends to hurt overall
system performance. The other issue is if you don't use value object you are
often bound to a more complex method signature so a change in the servers
method means you have to change the client, in reality the "domain" data
which is business data doesn't change much so using a VO to encapsulate this
data helps protect you from behavioral changes (business logic) which does
change more often than domain data.
 
If you really must call methods without value objects there is nothing in
fluorine to stop you.  
 
e.g.
 
class MyDotNetClass
{
 
            public void Hello(string message, int age, string description,
Job jobdesrciption)
}
 
You would duplicate those basic types in flash and create a Job class.  You
can call any method you like through fluorine, it will do its best to create
the correct object on the server.  You can also map a flash object to a .net
object with a custom xml setting in the web.config file, they document this
on their website.
 
I WOULD NOT recommend doing this, I would recommend a service based approach
using value objects.
 
 
 
Grant.
 
 
 
-----Original Message-----
From: Arp-bounces at ariaware.com [mailto:Arp-bounces at ariaware.com] On Behalf
Of Matt Brailsford
Sent: Thursday, January 26, 2006 11:36 AM
To: General List for Ariaware RIA Platform users and developers
Subject: Re: [Arp] Best practise: no VO's server side?
 
Basically all the demos available show the use of VO's both in flash and
server side, so flash builds a VO and sends it via a command to a service,
which reads the properties and does what it does with them, then returns a
VO or collection of VO's back to flash.
 
What if the service method does not accept a VO object as it's perameter,
but rather a series of properties (like normal methods)? I know flurine
doesn't care what you send, but ARP's design patterns are based around VO's
for data.
 
Is that any clearer?
 
  _____  

From: Arp-bounces at ariaware.com [mailto:Arp-bounces at ariaware.com] On Behalf
Of Davies, Grant M.
Sent: 26 January 2006 13:30
To: 'matt at gradiation.co.uk'; 'General List for Ariaware RIA Platform users
and developers'
Subject: Re: [Arp] Best practise: no VO's server side?
 
Matt, I'm not following you ?  Fluorine doesn't care what objects you send
it. I'm sending it a VO in my demo not a series of properties.
 
I'm using it in my own work for my website and I call a getProjects method
and return an array of project VO's...
 
Grant.
 
-----Original Message-----
From: Arp-bounces at ariaware.com [mailto:Arp-bounces at ariaware.com] On Behalf
Of Matt Brailsford
Sent: Wednesday, January 25, 2006 4:47 PM
To: Arp at ariaware.com
Subject: [Arp] Best practise: no VO's server side?
 
Hey guys,
 
Just wondered if anyone could offer any advice on the following.
 
I'm using fluorine remoting gateway with some .NET dll's that I don't have
control over and so as such there methods accept a series of properties
rather than a VO object.
 
Does anyone have any best practises to work this way? Other than having to
create .NET wrappers?
 
Many thanks
 
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ariaware.com/pipermail/arp_ariaware.com/attachments/20060126/685ae8c0/attachment.htm