[Arp] The right way to use VO/TO's
Davies, Grant M.
grant.davies at nscorp.com
Wed Mar 15 07:57:04 PST 2006
yes.
Grant
_____
From: Arp-bounces at ariaware.com [mailto:Arp-bounces at ariaware.com] On Behalf
Of Matt Brailsford
Sent: Wednesday, March 15, 2006 10:27 AM
To: General List for Ariaware RIA Platform users and developers
Subject: Re: [Arp] The right way to use VO/TO's
In your example, are the Order and OrderItem classes VO's?
_____
From: Arp-bounces at ariaware.com [mailto:Arp-bounces at ariaware.com] On Behalf
Of Davies, Grant M.
Sent: 15 March 2006 15:01
To: General List for Ariaware RIA Platform users and developers
Subject: Re: [Arp] The right way to use VO/TO's
I screwed up my example... sorry let me re-do the order bit :)
class GetOrdersRequest extends ServiceRequestHeader
{
var customerId:Number;
var startDate:Date;
var endDate:Date;
}
so this allows me to get orders for a particular customer between 2 dates.
the response should be a list of orders but this would be a "summary" of the
order not the actual order items as often you'd be sending back more detials
thatn you need
class GetOrdersResponse extends ServiceResponseHeader
{
var customerId:Number;
var orders:ArrayList;
}
so this allows me to get back the list of orders, the customerId is not
strictily necessary but may be useful.
now this should give me back an array of orders which could be :
class Order
{
var orderId:Number
var customerId:Number;
var createDate:Date;
var orderStatus:OrderStatus;
var shipDate:Date;
var orderTotal:Number;
var shipppingTotal:Number;
var subTotal:Number;
}
so now lets supposed I want to get the details of an order I'd create:
class GetOrderDetailsRequest extends ServiceRequestHeader
{
var orderId:Number;
}
I can send the order id to retreive
class OrderDetailsResponse extends ServiceResponseHeader
{
var detailId:Number;
var orderId:Number;
var orderItems:Array;
}
I get back the detail id and the array of order item objects so I may have
class OrderItem
{
var itemId;
var stockId:Number;
var description:String;
var quantity:Numberl
var chargedPrice:Number;
}
Things to remember, with the "request" and "response" objects I generally
have a 1:1 mapping to the server which could be considered the transfer
objects, the value objects, Order and OrderItem which could be considered
the valueObjects although they will map to an object on the server, they may
be an abstraction of a database table, for example I wouldn't link the price
of a "memory" chip to the actual table that contains all the things I sell,
because if the price changed then peoples orders would change, so the price
in an order item is the price that was charged when the order was placed,
but of course this is more of a business problem at that point that a ARP
problem.
I should blog this sometime soon :)
Grant
_____
From: Arp-bounces at ariaware.com [mailto:Arp-bounces at ariaware.com] On Behalf
Of Davies, Grant M.
Sent: Wednesday, March 15, 2006 9:28 AM
To: General List for Ariaware RIA Platform users and developers
Subject: Re: [Arp] The right way to use VO/TO's
I use a VO for most data objects but I tend to have a hierarchical VO
structure.
For example lets suppose your server side system has an error, how are you
going to get this to flash ?
what I tend to do is the following
(psuedo code, not compilable, just an example)
class ServiceRequestHeader
{
// who is asking, this could be a user id or an application id for logging
purposes
var requesterId:String
// if you need to pass credentials such as a password or "token" with all
calls, it should go in the class
}
class ServiceResponseHeader
{
// status code, unique to the this service, 0 could be "ok"
var statusCode:String
// message as text "the request was successful" if the status code was
nozero maybe its "the order id was not found in the system"
var statusMessage:String;
// a more detailed message usuaully for debuging purposes "Order id [4456]
was not found in table CustomerOrders", this will be used by the flash
developer during builing of the application
var detialMessage:String
}
Now when I have a application VO such as login I would do this :
class LoginServiceRequest extends ServiceRequestHeader
{
var id:String;
var password:String;
}
class LoginServiceResponse extends SerivceResponseHeader
{
}
now in this case the LoginServiceResponse does not need to return any data
other than status so I may not create an actual LoginServiceResponse but
lets look at another one such as "get order"
class GetOrderServiceRequest extends ServiceRequestHeader
{
var orderId:String;
}
class GetOrderServiceResponse extends ServiceResponseHeader
{
var orderItems:Array;
}
now in my code I can check the response for status code first from its
baseclass ServiceResponseHeader, then if everything looks good I'll go get
the orderItems from the real response class.
We have used the architecture successfull with AMF and with webservices in
both JAVA and with .NET for an application with aboug 100 value objects and
over 100 services (Its a security adminstration system with about 4000 man
hours in it).
Don;t get caught up in the transfer object / value object terminology, I
personally think we need to just leave the damn things alone and call them
valueObjects there are enough things to debate in the development world that
are for more important :)
Cheers
Grant
_____
From: Arp-bounces at ariaware.com [mailto:Arp-bounces at ariaware.com] On Behalf
Of Matt Brailsford
Sent: Wednesday, March 15, 2006 4:17 AM
To: General List for Ariaware RIA Platform users and developers
Subject: [Arp] The right way to use VO/TO's
Hi Guys,
I've noticed in a few posts it has been said that many ARP developers are
using VO/TO's in the wrong way.
I was just wondering if someone could clarify how they should be used?
Do you make a VO/TO for every data object? Or just when you want to send
that data back to the server?
If that later, how should one define data objects within there application,
for objects that don't require sending back to the server?
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ariaware.com/pipermail/arp_ariaware.com/attachments/20060315/8d315a37/attachment-0001.htm
More information about the Arp
mailing list