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: Is it ok for Proxies to gather information from other Proxies  (Read 4422 times)
Helmut Granda
Full Member
***
Posts: 47

Flash Developer.


View Profile WWW Email
« on: October 05, 2009, 10:56:28 »

Is it ok for Proxies to gather information from other Proxies or should I be going the other way around.

This is how my aplication is working:

User dispatches an event
Mediator sendsanotification
Command gathers that notification
ProxyA needs information from VO that belongs to ProxyB.

In this case, should I go all the way around and get a reference from ProxyB to gather the information I need from the VO that is connected to ProxyB or should I just get a reference to that VO directly on ProxyA.

The only issue why I am hesitant to get a direct reference on ProxyA and ProxyB from the same VO is because ProxyB is making changes to the VO.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: October 06, 2009, 06:34:40 »

There is no problem with two Proxies collaborating. They are somewhat at the mercy of the application to have registered their collaborators (i.e. if ProxyA needs to retrieve ProxyB, it can only assume the app has registered it already). One way to aleviate this problem is to have ProxyA register ProxyB itself during its onRegister. So these dependencies are taken care of in the Model tier.

As for the reference to a VO issue, it all depends on how you want things to work. If ProxyB owns the VO and ProxyA gets a reference to it and changes it, then ProxyB's VO has changed. Maybe you want that maybe you don't. You could clone the VO (add a clone method to the VO that creates a new instance, copies all the props over and returns the copy). Or you could have ProxyA do any updates to the VO by using methods on ProxyB which may send out notifications as they would if the view or controller regions had updated it.

-=Cliff>
Logged
sasuke
Full Member
***
Posts: 29


View Profile Email
« Reply #2 on: October 21, 2009, 01:57:34 »

Or if it is just the data you are interested in, you can retrieve the same in the mediator [assuming that both ProxyA and ProxyB are registered in the same facade] and then send the data as a notification body. This has the advantage of the Command not knowing where the data has come from. So if tomorrow, Proxy A in the command needs to use the data from ProxyC instead of ProxyB, the only change will be in the mediator. This is how the flow should be:

  • User dispatches an event
  • Mediator retrieves the data from ProxyB and sends a notification with the data in the body
  • Command gathers that notification and retrieves the data from the body
  • ProxyA uses the information *without* knowing anything about ProxyB

IMO, it's a win-win situation given that you get the data + the loose coupling.

And if ProxyB belongs to a different Facade, I'd recommend having a separate module which manages the flow of data to-n-fro along with data sharing between proxies so as to again facilitate for loose coupling.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: October 21, 2009, 07:48:29 »

@sasuke, that's perfectly fine if we're talking about a use case initiated at the view and an intrinsic part of the application we're writing.

However a key rule of RIA development is to keep the model as portable as possible. Today you may be building a Flex or Flash app for the web. But tomorrow you may be writing a desktop and / or mobile companion app that uses the same model, but exposes different use cases and or visual form factors (Adobe's Open Screen Project is all about this).

In those cases, we don't want to involve the View tier in the process of keeping the integrity of the Model. This is where it's good that Proxies be able to collaborate. So that when you move your model to a separate package to share between your apps, you don't need to also port over a bunch of view-related stuff from the application itself.

A Proxy can register other proxies, thus ensuring their presence if they need to collaborate by retrieving and executing methods on each other.

You also move all your complex multi-proxy manipulations (domain logic) into Commands to decouple the Proxies from each other. These commands should know nothing of the View, and should be strictly for manipulating the Model. When you go to repackage your Model into a library for sharing between apps, you may also package those Commands, one of which could be your PrepModelCommand which registers any domain logic Commands in the package as well as registering the Proxies.

This can leave you with a portable Model that can keep integrity across Proxies and doesn't require a lot of work to plug into a new app.

-=Cliff>
Logged
sasuke
Full Member
***
Posts: 29


View Profile Email
« Reply #4 on: October 23, 2009, 12:00:13 »

Oh, so you are saying that it's OK to expose dependencies between models/coupling between models when required instead of trying to hide it by involving the view in between. I thought according to the MVC paradigm, it was OK for the View or the Controller to modify/influence the model tier?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: October 23, 2009, 03:47:20 »

I thought according to the MVC paradigm, it was OK for the View or the Controller to modify/influence the model tier?

This is true.

However, when MVC is applied to an RIA client, it is important to isolate the Model and its attendant domain logic so that it can be reused cleanly in other applications.

Even if it is not planned at the moment, ALWAYS assume that the web client that you're writing today will also have desktop and/or mobile counterparts tomorrow. They will talk to the same model, but they will expose different use cases at the View. Therefore it is imperative that you not include domain logic in the View tier of your app.

-=Cliff>
Logged
sasuke
Full Member
***
Posts: 29


View Profile Email
« Reply #6 on: October 24, 2009, 12:24:49 »

Cool, I'll keep that in mind; thanks for the explanation. :)
Logged
Pages: [1]
Print