PureMVC

QUESTION: 

• Felix (author of MiniTask) asks:

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>