What's wrong with this Command?

[Elephant]

I saw this architecture and immediately said "Whoa, that's working against the PureMVC structure!", but I can't really explain *why*, other than saying "Commands are supposed to be stateless" which isn't much more than a statement of religious doctrine


public class FooCommand extends SimpleCommand {
  private var fileTransfers:Array = [];
  private var transfersComplete:int = 0;

  override public function execute(notification:INotification):void {
    //The following happens in a loop in the actual class:

    var someFile:File = new File(someLocation);
    //Logic to make sure the file exists goes here

    //FileTransfer is a helper class that wraps FileStream logic for actually reading the file
    var fileTransfer:FileTransfer = new FileTransfer(someUrl);
    fileTransfer.addEventListener(FileTransfer.TRANSFER_ERROR, this.transferError);
    fileTransfer.addEventListener(FileTransfer.TRANSFER_COMPLETE, this.transferComplete);
    this.fileTransfers.push(fileTransfer);
  }

  private function transferError(event:Event):void {
    sendNotification(MyFacade.ERROR_WITH_FILE_TRANSFER);
  }

  private function transferComplete(event:Event):void {
    //Omitted logic making sure the fileTransfers array is empty

    sendNotification(MyFacade.FILE_TRANSFERS_COMPLETE);
  }
}

[puremvc]

The philosophy of PureMVC has been one of using long-lived actors in the Model region for server communications rather than commands which are short-lived.

As for whether that philosophy lies in the realm of religion, it's certainly debatable. While MVC has a primary goal of helping to cut down on the spaghetti code by slicing the app along reasonably surveyed lines, in the case of a rich client we get a second major benefit; the ability to reuse the Model with various clients (which is handy for desktop, mobile and web apps that talk to the same services). You'll see me point this out again and again in the forums, like a mantra. Keeping the broad goals of PureMVC in site, helps guide you toward the right solution in your architecture, just as commandments and other religious tokens are meant to guide you to the right answers in the randomness of everyday life without actually defining exactly what you should do every step of the way.

The roles and collaborations of the actors are well defined, but when it comes to spreading the logic around your app, you have to find the right place for things based on abstract framework goals and your local situation.

The mantra says: If you put the service code in the Model (via a Proxy), you can then use that service and all the other services your app talks to in another app. i.e. a desktop version of a web app.

But this specific logic requires the desktop AIR libraries. Therefore it couldn't really be reused in a Flex web app, and couldn't go into a library to be shared by both projects. So, placing it in a command might be fine, since that's going to be code that's unique to your AIR application.

That assumes the simplest multi-app case of desktop and web trying to share as much of the Model as possible. But maybe you've got a series of AIR apps (never Flex apps) that need this same functionality. Does it make more sense to move that code into a Proxy, very possibly. The FileTransfer class might become the FileTransferProxy which you register once and later retrieve as often as you like and queue transfer requests. If nothing else you can possibly eliminate time spent on repeated object creation associated with the command.

-=Cliff>