Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought

Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Author Topic: Object Registry and object unicity  (Read 8829 times)
Posts: 3

View Profile Email
« on: September 17, 2009, 08:30:02 »


I'm working on an application which use Maven/Java/Flex with spring framework and blaze ds for the server side and puremvc for the client side.

I have a lot of proxy which load object list and store them in order to populate some datagrids and combo boxes.

My problem occurs when I'm loading an object which have some other referenced objects.
If one of these referenced object have been already loaded by another proxy, I obtain 2 instances of the same object

Do you know a way to control the instantiation of new object decoded from AMF message ?
(I debug as3 code until the famous ObjectInput class and then the nil..., Ididn't found a way to control the object creation, even with the externalizable api)

Is-it possible to build an object registry based on business object key on the client-side. (I already build one in Java for a RCP application)

All suggestions are welcomed !!

Global Moderator
Hero Member
Posts: 2871

View Profile WWW Email
« 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.registerProxy(new Proxy("Nitz"+nitz.id, nitz));

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

« Last Edit: September 17, 2009, 10:59:38 by puremvc » Logged
Posts: 3

View Profile Email
« Reply #2 on: September 21, 2009, 05:00:52 »

Ok thank you for your answer...

Actually I don't use one proxy per object, it would cost too much memory because we can have a lot of objects (many thousands), our proxies store a list of objects and are used to call remote service. (perhaps I'm wrong and I should use one proxy per object)

So I should build an object registry which will be updated after each remote call...

In that case I will probably build a notification engine with the help of JMS.
I have a comparison engine written in Java which will be able to send to all clients the modifications done on an object.

I will re-work on this subject later. I keep it in my mind and I will write you some feedbacks soon

Pages: [1]