puremvc
|
![](http://forums.puremvc.org/Themes/PureMVC/images/post/xx.gif.pagespeed.ce.G0yTW6LI8E.gif) |
« Reply #1 on: September 17, 2009, 10:40:15 » |
|
Do you control the service design? If so, you probably need to address this on the server rather than the client.
Without deep surgery to Flex, you can't keep the client from deserializing the data that it receives but by that time, the damage has been done in terms of bandwidth consumption. Even if you weren't experiencing issues in your view as a result of this problem, you'd still want to optimize the services such that you send your data in a more granular fashion.
For instance: * You have a complex object called 'Frob', which has a complex property called 'nitz'. * You send a request resulting in 20 Frobs being returned from the server. * All or many of the Nitz objects may refer to the same entity. * This wastes as much as 19 Nitz's worth of data transfer time and bandwidth.
To correct this with a service redesign 1) If entity redesign is possible, make the Frob.nitz property a Frob.nitzID property instead. * This ensures the minimum amount of data is transfered
2) If entity redesign is not possible, * When sending a Frob, populate the nitz property with a bare Nitz object that only has the ID for that Nitz entity. * When the client recieves the Frobs, make a list of the unique Nitz IDs that you need. * For each Nitz to be requested, also keep a list of the Frobs that need the speicific Nitz. * Send off requests for the required Nitzs.
To create an object registry of Frobs and Nitzs on your client independent of the service proxy and retrievable by ID, simply:
A) In the FrobServiceProxy, when results come back, register a bare Proxy for each Frob with the FrobID as the Proxy name and the Frob as the data.
facade.registerProxy(new Proxy(frob.id, frob));
B) In the NitzServiceProxy, when results come back, register a bare Proxy for each Nitz with the NitzID as the Proxy name and the Nitzas the data.
facade.registerProxy(new Proxy(nitz.id, nitz)); C) Note that A and B above assume Frob and Nitz IDs are unique and not simply record numbers. If the latter is the case, you want to prepend "Frob-" or "Nitz-" to the the ID used to register and retrieve your Frobs and Nitzs so that Frob #12 is distinguishable from Nitz #12:
facade.registerProxy(new Proxy("Frob"+frob.id, frob)); ... facade.retrieveProxy("Frob"+frobID);
or
facade.registerProxy(new Proxy("Nitz"+nitz.id, nitz)); ... facade.retrieveProxy("Nitz"+nitzID);
D) In the NitzServiceProxy, if you had to choose course 2 above, then you need to go through your Frobs and add references to their Nitz's. * Remember in course 2 above, you were supposed to keep a list of which Frobs needed a specific Nitz? * When you make a service call for a given Nitz, you can use the AsyncToken returned by the service call to remember which Frobs need that particular Nitz:
public function fetchNitz( nitzID:String, frobs:Array):void { var token:AsyncToken = nitzService.fetchNitz(nitzID); token.frobs = frobs; }
public function fetchNitzResult( event:ResultEvent ):void { var nitz:Nitz = event.result as Nitz; facade.registerProxy( new Proxy( nitz.id, nitz ) ); // Nitz can now be retrieved by id var frobs:Array = event.token.frobs as Array; // The needy Frobs for each ( var frob:Frob in frobs ) { frob.nitz = nitz; // give the Frob a reference to the Nitz it needs } }
-=Cliff>
|