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]
Print
Author Topic: Call proxy from VO?  (Read 8022 times)
Krazz
Newbie
*
Posts: 3


View Profile Email
« on: July 15, 2011, 12:16:34 »

Is it bad or OK to call a proxy from a VO?

If it's not OK, why not?

Let's say I have two different proxies, one for cars and another for car parts used on different cars. If I open a car part I will have the ID to the car it fits on, so why can't I retrieve the car proxy in the VO and return the related car VO right there?

:
package com.carparts.model.vo {
public class CarVO {
public var IDCar:int;
public var Brand:String;
public var Wheels:int;
public var Color:String;
}
}

package com.carparts.model.vo {
import com.carparts.ApplicationFacade;
import com.carparts.model.CarsProxy;

public class PartVO {
public var IDPart:int;
public var IDCar:int;
public var Price:Number;
public var Size:Number;
}

public function get car():CarVO {
// The CarsProxy has a dictionary of all different cars indexed by IDCar.

var carsProxy:CarsProxy = ApplicationFacade.getInstance().retrieveProxy(CarsProxy.NAME) as CarsProxy;
return carsProxy.carsDictionary[IDCar];
}
}
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: July 15, 2011, 08:53:30 »

No, it's not. The VO is meant to be a data-carrier that is passed across tiers without being bound to any of them. It should not be bound to the framework. The Proxy wraps the VO, providing access to it from the rest of the application. Logically, having a VO access its Proxy is like having a fortune cookie contain its own wrapper.

If the VO needs access to another VO (in this case the PartVO needing access to the CarVO it is a part of), then add a property on the VO for the CarVO, and set it from the Proxy.

It is helpful to think of VOs and view components to be babies. They are spoonfed by their nannies, the Proxies and Mediators. When a baby is hungry, it doesn't go to the fridge and get its own food, instead it cries and the nanny feeds it. When it needs its diaper changed, it cries and the nanny changes it. Sometimes the nanny bathes it because it knows it's time for a bath.

Taking this metaphor to PureMVC, on the view side, a view component needing data or wanting to send data dispatches an event that the Mediator hears, then the Mediator can either retrieve the data and feed the baby, or echo the cry by sending a Notification, which is handled by a Command, and sent back by note to the Mediator who feeds the baby. On the model side, the VO is usually not vocal, but tended because its time for tending. A new PartVO arrives from the service in the PartProxy, and it takes the carID and consults the CarProxy to get the reference to the CarVO and set it on the PartVO.

Hope this helps,
-=Cliff>
Logged
Krazz
Newbie
*
Posts: 3


View Profile Email
« Reply #2 on: August 01, 2011, 05:39:57 »

Thank you Cliff.

Now a follow-up question in relation to the topic.

Instead of adding a getter in the VO, what if I create a variable called car that will hold the CarVO that will be filled when I receive the parts.

Explained in a more logical manner:
1. Cars are received into the CarsProxy and stored in an Array of CarVO's.
2. Parts are received as an array and looped through to add a carVO to each of the parts.

PartVO would look like this:
:
package com.carparts.model.vo {
public class PartVO {
public var IDPart:int;
public var IDCar:int;
public var Price:Number;
public var Size:Number;

public var carVO:CarVO;
}
}

This way I can get to the car information quickly and painlessly.

The question is if this will bind up more memory on the client computer or not? Maybe there are some other drawbacks of doing it like this?

/Goran
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: August 01, 2011, 07:46:18 »

You can do that. You just need to remember to treat that carVO as transient.

If you're using BlazeDS, LCDS or WebORB to communicate with the server using RemoteObject, the PartVO on the actionscript side would look like this:

:
package com.carparts.model.vo {
public class PartVO {
public var IDPart:int;
public var IDCar:int;
public var Price:Number;
public var Size:Number;

[Transient]
public var carVO:CarVO;
}
}

If you're not using RemoteObject and are instead passing JSON or XML back and forth to and from the server, you need to remember to null out the PartVO.carVO property before sending it back to the server if you are updating it or saving a newly created one.

-=Cliff>
Logged
Deril
Full Member
***
Posts: 22


View Profile Email
« Reply #4 on: August 06, 2011, 11:19:37 »

I would still question implementation...

 Car part should not care about car it is on in any way.

 We talk about data here..

 Lets say property of part changes. this is job of Proxy to alter it as Cliff mentioned. Lets say then part is changed Car data must be affected somehow... now we have 2 options :

 1 logic involved
 2 no logic.. just data.

if logic is needed... that's it.. it's work of command to care about it all.. it should set car data and car part data by using proxy on its own. If action needs some decision making - create command.

if no logic is involved.. but some arbitrary data must be altered... lets say car has weight, every part adds weight for the car... every time then proxy adds part to the car, it could recalculate car weight and just set it. Its data stuff. no logic is needed here.

 even arbitrary check like...

:
if(part[i].hasWeight){
     car.weight += part[i].weight
}

is ok here.. again - data stuff.


in any case.... part is just a part... it should hold part data and should be ignorant on whatever car... shelf... trash-bin it is placed in.

rethink your OOP architecture.


PS : it's the same thing with view, the only difference is that view car-part might be active object, not like car-part data object. And as active object this object can do stuff on its own sometimes. Still it should be ignorant about car it is in' and should send event to talk about jobs it does. If it is in the car... car will be affected by this event somehow. Lets say... radar installed in the car can send signal about police post in front.
 Meanwhile in lot of cases this car-part can't do stuff on its own... lets say... wheel can't spin on its own. Car must spin them, in this cases car should manage its parts and use them.

 Think OOP - it will lead you to most intuitive implementation and in almost all cases - proper architecture.

Have fun.
« Last Edit: August 07, 2011, 02:06:17 by Deril » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: August 08, 2011, 08:46:30 »

For the most part, I would agree. But a linked list is also an OOP pattern, and like all patterns, it can be just the thing you need or it can be a bad fit. That's why I didn't question the linkage.

Sometimes you want a link both down the hierarchy and back up it. If the car object has a part and the part is edited by a view component that only takes a part, then upon submission of the change at the UI, you may wish to have the car that the part is a part of be flagged as having been changed, so that the model may then notify another part of the view (perhaps one that highlights cars that have been modified).

If you had a great many cars each with a great many parts, then having a modified part in hand and having to iterate through all the cars and their parts to find the one that this particular part belongs to would likely require many more CPU cycles than simply following the link on the part back to its specific car.

-=Cliff>
Logged
Pages: [1]
Print