Recently I have been making the transition from PureMVC to Parsley, and have found many parallels regarding de-coupling and separation of concerns.

Just to provide some brief background:

PureMVC is essentially an observer Pattern.

Parsley is an IOC Container and Messaging Framework

As it is a Dependancy Inject pattern, it is a style of object configuration in which an objects fields and collaborators are set by an external entity. Parsley achieves this through allowing the coder to specify a configuration that holds information about what is to be injected and what message handlers may exist. But the code base of a project would be decorated by Injection tags, or Message tags.  There is NO direct coupling to the framework.    But the most noticeable difference between the two frameworks is the dependancy that exists on the PureMVC framework.

PureMVC is a framework where you are constantly extending classes or implementing interfaces from the framework itself, thus leaving the project completely dependant on the framework, making it difficult to re-factor if a better framework were to come along.

For example a command in PureMVC would have all this code to contend with:

public static const MY_NOTIFICATION:String = "myNotification";

// Facade declaration

facade.registerCommmand(Notification.MY_NOTIFICATION, MyCommand);

//Command Declaration

public class MyCommand extends PureMVCSimpleCommand {

public override function execute(notification:INotification):void {

var med:MyMediator = facade.retrieveMediator(MyMediator.Name) as MyMediator;

var proxy:Proxy = facade.retrieveProxy(MyProxy.Name) as My Proxy;

proxy.doSomethingToUnderlyingModel();

med.presentationModel = proxy.presentationModel;

}

}

In the example above the code is heavily coupled to the framework, and is not easy to reuse as it uses specific class implementations ignoring the benefits of polymorphism.

The same is achieved via the following in Parsley:

// for the sake of demonstrating polymorphism

Presentation Model implements IModel

MyView implements IView

// The configuration for the current context

(mx:Object)

(parlsey:Object type={PresentationModel}/)

(parlsey:Object type={MyView}/)

(parsley:Object type={MyCommand})

(MessageHandler method="execute" scope="local"/)

(/parsley>

(/mx:Object)

public class MyCommand {

[Inject]

public var model:IModel;

[Inject]

public var view:IView;

public function execute(event:DataEvent):void {

model.doSomething(event.data);

view.model = model;

}

}

The parsley example does a number of things well:

PureMVC does indeed do what it says on the tin, but in order to do so a huge dependancy is built on the framework itself, and a lot of code is needed to setup your application.  There is a danger with Parsley that a not so experienced developer could strongly couple models and views together as there is no clear convention like PureMVC, but on the flip side it is extremely easy to avoid as the object dependencies are not applied until specified by an external container.  And there is no reason not to keep the views and models separated with parsley.

The Parsley framework is largely based on the excellent reflection framework (SpiceLib) available from spicefactory.org, which makes the injection model not only possible but also possible to extend.  Jens Halm (creator of SpiceLib and Parsley), makes it easy for developers to extend the framework via a clear documentation and supplies the source code as well.  If a developer wanted to create a new Tag for some kind of injection and is not sure how to go about it, just look to the online documentation and the code for the Parsley library.

Conclusion

It was a pleasure to have developed with PureMVC over three years, and the supporting documentation is the best I’ve seen.  Before Parsley existed I had to choose a framework for my developers in a previous role, and amongst its then competition Cairngorm it was an easy choice.  It clearly separated models from views and dealt with many good coding and architecting principles.  But there is an expensive future cost; unfortunately a huge dependancy is built on the framework, it would be mammoth task to re-factor away from PureMVC should you find something better or PureMVC is no longer supported.  PureMVC does provide a mechanism of reusing your code, but is diminished by the fact that it is easy to create mediators, proxies and even commands that are to specific to the context that they are intended for.  It has recently added the ability to allow communication between modules via its new pipe library, but its extremely cumbersome to use and almost impossible to debug.

Parsley as a framework is impressive, as it manages to IOC itself away from the developers code base.  If in the future I need to migrate to a different framework, I only need to change the tags or manipulate the configuration to work with the new framework; but 95% of the code base does not have to change.  The developer is not forced to inherit or implement from the framework itself.  As a result of a decoupled framework there is no reason why this could not be used in congestion with other frameworks.  But Parsley unlike many other frameworks provides a clear and intuitive messaging buss.   Parsley also takes into account the the context of an application area, and enables the developer to dispatch or handle an event in the scope of a local context, parent, custom or global context.  This provides a communication mechanism between different parts of your application, using flex’s own event api.  For example when dealing with modules, each module will have its own individual scope, but can communicate with each other via a custom scope which contains the context of each module.  Parsley is powerful in terms of what it allows the developer to do using the clear approach of IOC.  There are almost no dependancies in the structure, and it facilitates a lot of functionality with very little code.  Classes can be reused using the injection framework and polymorphism, with a minimal effort.