RPC calls handling reponses and IOC

[zilet]

Hello all,

   I am building big application that has many modules and has very heavy database interaction. Application server is Java and for the front end Flex is used with PureMVC. I wanted to discuss about best practices in handling rpc calls. There are a lot ways to manage this but I will present ones that I consider good:
 
  1. BusinessDelegate that represents the DAO class. This Business delegate is then used in a Command to execute some of the DAO operations (eg. insert, delete, update). Mediators send notification when user requests operations. Every command is a Responder and sends notifications when rcp op is complete which mediator listens for.
     Good thing: this way it is easy to make different BusinessDelegates (WebService, HTTPService, RemoteObject) and provide it to the command
     Bad: there are a lot of Commands
  2. Proxy represents DAO class. Mediator calls the method in proxy as it would call DAO method and listens for notification that proxy will return.
     Good: very clean
     Bad: nothing special

So I am going with the second approach as I consider it better. Do you have some other ways of handling these?
I have here a so called issue if multiple mediators use the same Proxy class and they all get updated when Notification is returned. I consider this a good thing because this way the view is staying consistent and I didn't find a case when this is unwanted. But if in some case this is unwanted, all of the public methods of Proxy return the AsyncToken, so in mediator it is possible to add custom responder.

The other thing is some IOC framework that I require here. It would be great to easy (configurable through xml, or some other ways like in spring) provide to Proxy some other way of accessing the data (remoteobject, webservice, etc). So did anyone used some ioc container with puremvc?

[tobydeh]

The second option is pretty much correct.

Make your own RPC DAO Class, or use the Flex HttpService etc then your Proxy uses that class to interact with the back end.

Your Commands do not need to interact with any DAO.

[JCabot]

Another idea, instead of using the AsyncToken and custom responders in the mediators, is to use some kind of shared data between the mediators and proxy, then test on this when a notification is received (an example is probably the best way to describe what I mean)

:

Mediator:
protected var key:String = "someKeyForThisMediator";
protected function onKeyPress(event:Event):void
{
proxy.doSomething(key);
}
override public function handleNotification(notification:INotification):void
{
switch (notification.getName()) {
case ApplicationFacade.DO_SOMETHING_RESULT:
if (notification.getType() == key) updateView(notification.getBody());
break;
}
}

Proxy:
protected function doSomething(key=null):void
{
service.addEventListener(ResultEvent.RESULT, onDoSomethingResult)

var token:AsyncToken = service.send();
token.key = key;
}
protected function onDoSomethingResult(event:ResultEvent):void
{
var key:String = event.token.key;
sendNotification(ApplicationFacade.DO_SOMETHING_RESULT, event.result, key);
}

The advantage of doing it like this means that the mediator doesn't need to know that the proxy is calling a service, it just needs to know that it only updates the view when it receives a certain key in handleNotification.

[DEfusion]

So are you guys saying you have your mediators talk direct to your proxies.

I currently have it so that the mediators send a notification that they want some data, then a command usually just gets the proxy and tells it to get the data, when the proxy has it's data it sends a notification that the data is retrieved.

There are some instances where the command gets something in the notification body, but that's usually passed straight onto the proxy when we ask it to get the data.

[DEfusion]

What about having the Command act as a Responder (by implementing IResponder) and the execute method basically creates a delegate and then calls the appropriate method. That seems cleaner than what I'm currently doing.

[zilet]

Well to me the most clean method is that proxies represent service objects and mediators all directly their methods and wait for notification to retrieve data.

With Commands as Responders you can end with dozen commands for one service object. For instance if you have DAO object with insert, update, select, getAll, delete methods you should have for each table all the commands that handle this and in the mediator you would have to send a dozen of notifications and also register all this commands which leads to a total confusion.

By using proxies and directly calling its methods you are having one entry point and have a clean way of knowing what to expect to be returned.

But, I didn't hear anything about IOC in Flex. I found Parsley from spicefactory.org and it looks very promising but I didn't use it. What do you think about this?

[puremvc]

DEFusion:
Please have another look at the Best Practices doc, which has been updated recently and talks a bit more about these relationships.

In short use the proxy as the responder and send notifications when you are done.

Also, search these forums for 'MVC2', the late model server-side mvc. In that discussion, we're talking about PureMVC on server side, but I also discuss why its ok for the mediator to talk to the proxy.

Zilet's post above really gets to the heart of it, though:

Well to me the most clean method is that proxies represent service objects and mediators call directly their methods and wait for notification to retrieve data.

With Commands as Responders you can end with dozen commands for one service object. For instance if you have DAO object with insert, update, select, getAll, delete methods you should have for each table all the commands that handle this and in the mediator you would have to send a dozen of notifications and also register all this commands which leads to a total confusion.

By using proxies and directly calling its methods you are having one entry point and have a clean way of knowing what to expect to be returned.

-=Cliff>   

[DEfusion]

Okay, I've reviewed the new best practices document and that has cleared some things up.

I currently have some Delegates which are responsible for doing the actual sending of the HTTPService request, and they accept a IResponder as the argument to the constructor. I think this is where I was going wrong, it adds an extra layer of abstraction that may not be needed. However it is nice to be able to test that it is creating the dynamic URLs correctly.

One thing I don't want is lots and lots of HTTPServices kicking around some of which will only get called once during the entire life of the app, so I was working with disposable HTTPServices, thus the IResponder being passed to the delegate when it's created and that being provided to the temporary HTTPService when it was called. I also somewhere along the way mis-understood proxies (it was actually a while between me reading the 101 courseware and then starting to implement PureMVC in my app so that's probably why).

So what's your the consensus with HTTPServices within Proxies, say I have a RoleProxy which is CRUD-like but allows listing of all the Roles do you have 1 HTTPService for each of the methods (5 in total) with associated event handlers (so maybe 5 result handlers and one fault handler -- depending on how granular your error handling needs to be), or something else.

Also as an aside I have tinkered with IOC in Flex (using this DI framework: http://thefoundry.anywebcam.com/index.php/actionscript/di-as3-released/) but once our app moved to modules it became difficult to work with DI.

[DEfusion]

Just read this post http://forums.puremvc.org/index.php?topic=68.msg241;topicseen#msg241, I was thinking of using the token (although my delegates don't currently return it) - I'm thinking of keeping the delegates they currently don't really do much but what they do (setting the parameters for the HTTPService send) is abstracted away from PureMVC so that seems cleaner to me, although it is another layer to manage.

[puremvc]

No problem with keeping the Delegate. This is a good pattern and not shunned by PureMVC. It is great to augment with. The only reason it's not part of the framework is it's not absolutely necessary.

Since the Model is the region they're used in, if you put them in a business folder, put that under the model package of your app like: com.me.myapp.model.business.MyDelegate.as

You can put them anywhere, but by following convention, your app will be more recognizable to some future PureVMC developer you may hire to help you extend it.

See how the CafeTownsend demo, which uses a Delegate has been refactored:
http://puremvc.org/pages/demos/AS3/Demo_AS3_Flex_CafeTownsend/srcview/

-=Cliff>