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: Remote proxy result/fault notifications and related commands  (Read 11281 times)
thedriver
Courseware Beta
Newbie
***
Posts: 2



View Profile Email
« on: March 21, 2008, 08:09:41 »

I currently have multiple remote proxies that return result and fault events for multiple remote methods in each.  On the result or fault event I use a switch statement to detect which remote method triggered the event and then send a notification specific to that combination like this:

ApplicationFacade.USER_PROXY_GET_USER_RESULT_EVENT
or
ApplicationFacade.USER_PROXY_GET_USER_FAULT_EVENT
or
ApplicationFacade.USER_PROXY_UPDATE_USER_RESULT_EVENT
etc.

Each of these is mapped to a matching command that deals with the event results.

I was thinking that I could greatly reduce the number of notifications and commands by issuing a generic fault and result notification for each proxy and then putting the switch logic inside the commands.  It would look like:

ApplicationFacade.USER_PROXY_FAULT_EVENT
or
ApplicationFacade.USER_PROXY_RESULT_EVENT

and inside the two mapped commands the switch would call methods specific to the remote method that triggered the event notification.

This would result in commands that were larger and contained code related to all the remote methods for a given proxy vs. a bunch of smaller more specific commands.

Does anyone have an opinion on which approach is better?  I like the idea of fewer command files and grouping the related method result handlers in one place (which actually match the methods of the remote class that the proxy is talking to).  I just have a feeling that there is some bigger architectural theory that I'm missing that would prefer the many notifications / commands way that it's currently headed.

I did just read the post about using named constants inside commands and notification types, neither of which I'm currently doing but both of which I'd like to use where appropriate.  My current command logic (and mediator logic) is driven by various properties of a generic "argsIn" object that I pass around in the notification bodies.  It seems like I should be using the notification types and named constants as at least a first level of decision making in the commands and mediators - I'm just not clear on how that code would look.

Hopefully some of the above makes sense, any advice, thoughts or best practice examples on this stuff would be most appreciated.

Thanks,

Chris

P.S. Thanks again for everything Cliff!
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: March 22, 2008, 06:14:42 »

Hi Chris,

I would suggest having a look at the Best Practices doc, which has been updated recently with more clarification on domain logic vs business logic.

Sounds like you're having one Proxy do all the service calls then having Commands parse the returns and manipulate the appropriate Proxy. This pushes domain logic into the controller region.
 
In short I think you need a Business Delegate class that owns the service, and exposes methods for the calls.

Then multiple Proxies to talk to the Delegate, one for each unique domain entity.

The Delegate makes the call and sets the calling Proxy as the responder for result and fault.

Then each Proxy is working with its on returned data.

The point of the Proxy is to encapsulate management of the domain data it manages. Busting that work out into a Command makes that Proxy less portable and breaks the encapsulation.

-=Cliff>
Logged
sectore
Courseware Beta
Full Member
***
Posts: 29



View Profile WWW Email
« Reply #2 on: March 22, 2008, 06:49:59 »

thedriver,

may I ask you what do the Commands execute retrieving Notifications from Proxy?

A Proxy or a RemoteProxy as a part of a Model sends a Notification to notify all interested Views when its data has been changed. That means all Mediators can listen to these if they are interested using its method called "listNotificationInterests" and can handle it using its function called "handleNotification". For this issues you don't need a Command and it might be a uncommon way to update a Mediator (View) from a Proxy (Model) using a Command (Controller).

If you want to manipulate other Proxies after receiving a result in your RemoteProxy it might be a way using a Command to map the Notification and to manipulate the others Proxies. But you could manipulate a Proxy from the RemoteProxy directly using "facade.retrieveProxy(AnotherProxy.NAME) as AnotherProxy;" as well if you have to solve this issue only once. One way to reduce the number of Commands.

For reducing the number of Notifications: If there a need to make a difference between Notifications for all faults? As you've already written you could use only a Notification called "ApplicationFacade.GET_DATA_FAILED" to handle all data errors. To show different error messages (e.g. using a PopUp) use the Notifications "body" object holding these messages.

For handling different results such as getting new user data or updating user data I would use different Notifications as well. So any interested member has the choice to listen to it or not without distinguishing the result.

@Cliff: As I see, you've already answered. Sorry, my post in English needed some time :)

-sectore




« Last Edit: March 22, 2008, 06:57:09 by sectore » Logged
thedriver
Courseware Beta
Newbie
***
Posts: 2



View Profile Email
« Reply #3 on: March 22, 2008, 05:40:40 »

Wow, thank you both for the detailed replies.  The way it's currently setup I do have a single business delegate that connects to the remote services and a "remote" proxy for each VO, ie: UserProxy, MemberProxy, etc. (which are setup as the event responders to the business delegate).

I'm round-tripping crud operations and up until now have used commands as a logic layer between the view mediators and proxies for data flowing in both directions.  It made sense to me for the commands to be the "brains" and for them to tell the mediators and proxies what to do along with passing in or setting the data they need to do it.

It's been working like this but obviously I want to be doing things the right way.  I will look at the updated docs and try to better understand the correct location for the various logic in the app.

Thanks again for your help and patience, I still have a lot to learn!

Chris
Logged
Pages: [1]
Print