topleft
topright

OReilly PureMVC Book

PureMVC Book

PureMVC TV

PureMVC TV

PureMVC on the Web

PureMVC Blog-o-Sphere
PureMVC on LinkedIn
 
Image
 
Why not use Commands as Async Responders?
Wednesday, 09 July 2008

QUESTION: 

 

As the Command is instantiated and executed locally in a controller function, theoretically the Command object is immediately available for garbage collection when the method finished executing, right?

 

Now what if you setup asynchronous event listeners in the Command's execute function?

 

Everything was fine in my case and events were fired and executed correctly but I nevertheless felt a bit unsure about it... quite a few things have changed in AS3 with GC and one can easily run into a situation where listeners aren't executed because the source already has been collected.

 

ANSWER:

  • Within a PureMVC application, there are a couple of reasons:

 

1. Commands should be stateless.

 
They are the object-oriented equivalent of a subroutine - a little place for us to break down to some procedural code, which is by definition synchronous in nature. By making a running Command a responder to an async process like a service call, you have given it state. It is in a waiting state. If it has a long timeout and the user clicks a 'stop' button, how do you interrupt it? You can't. You can have another Command tell the delegate to cancel the HTTPService call, but does that free the reference to this Command, which was on the responder list for the call?

You have handed a reference to a Command to another framework that you don't control. You have no way to ensure that that reference will eventually resolve to a result or fault callback (and that the framework has cleaned up its reference before returning) that will collapse scope and make the Command go away. Also, remember this pattern is implemented on multiple platforms, so any assumptions about the how the reference will be resolved by other framework (Flex, J2ME, etc) may not hold universally, so the practice must be one that can be advocated on any platform..

Meanwhile a Proxy is a registered, long-living actor and the framework has a method for removing it or retrieving it (for instance to tell it to cancel an operation). The framework can only remove a mapping for a Command. This is why we only have the Controller create and execute Commands and we avoid giving them state so they get their work done and go away, and we control their scope.

2. This is Domain Logic not Business Logic.

 
There is a distinction between the two. Business logic is concerned with coordinating valid interactions between View and Model. Domain Logic is about keeping an internally consistent Model representation on both sides of the app (client and server).

The Proxy's job is to hide the location of the data, and make it irrelevant to the rest of the application. The View and Controller regions need only know that a particular Proxy wants to be communicated with in a synchronous fashion or async.

This is why services have been entirely relegated to the Model region. You can write a more portable Model this way.

Several applications with different use cases and View/Controller arrangements may employ the same Model classes without having to reimplement or copy the code for keeping the Model internally consistent. 

 

-=Cliff>

Delicious
Technorati
Reddit
Furl it!
NewsVine
YahooMyWeb
Stumble
blogmarks
Digg
co.mments
connotea
 
Copyright (c) 2006-2012 Futurescale, Inc.