PureMVC: First thoughts & FlashDevelop templates

For those who aren’t interested in this blog and just want to get the FlashDevelop templates for PureMVC 2.0.3 you can download them here!

I’ve been meaning to have a good play with PureMVC for a while, and finally found some time a few days ago to check it out. For those who don’t know, PureMVC is one of a few Actionscript Model-View-Controller (MVC) frameworks for Actionscript. Two big established frameworks are ARP and Cairngorm (for Flex), and there are a bunch of other less well known frameworks, lots of which are available from OSFlash.

Personally I’m looking to get a few specific things out of my MVC framework:

  • Encapsulated concerns, high cohesion and loose coupling
  • Minimum configuration & ease of coding
  • Ease of maintenance

I’ll talk about each of these things separately. At this point I should point out that I have only been working with PureMVC for a little more than a day (that’s why it says first thoughts in the title), and some of what I’m saying here might be wrong! Any discussion on these points is gratefully received.

Encapsulated concerns, high cohesion and loose coupling

PureMVC takes a slightly different approach to the MVC design pattern than the official (if there is such a thing) stance, adding a bunch of extra design patterns into the mix. The View, Model and Controller are Singletons with access provided through a central Facade which is effectively the entrypoint and hub of your application. Models are then implemented as Proxies, controllers as Commands and views as Mediators. Communication between object is mostly done using PureMVC’s own Notification system rather than AS3 Events – this seems an odd design decision, but now that PureMVC is being ported to a whole host of different languages which do not support AS3 Events (Ruby, Python, HaXe, etc) this makes sense. I haven’t yet delved into the code to see if AS3 events are being used under the hood but if they are not, and if this performance boost was required, I imagine it would be fairly easy to implement. Note that AS3 events are still used on the visual side of things (i.e. between the Views and their Mediators).

Implementing the model through a proxy makes excellent sense, and makes the implementation of the model transparent to the rest of the application. All the app needs to care about is whether the call is synchronous or asynchronous and it should be possible to swap models around to your heart’s content. In fact, I’m sure it would be possible to ammend the Proxy such that all calls are treated as asynchronous giving complete transparency to the rest of the app.

Implementing controllers through commands is tried and tested, and pretty common. Its always worked fine for me. One nice touch that PureMVC adds is to allow direct mapping of Notifications->Commands with code such as:

   1: registerCommand(STARTUP, StartupCommand);

Nice and easy :)

The View/Mediator decision is a little more controversial, and I’ve read more than a few bloggers who find this a serious flaw in PureMVC. I can certainly see the motivation for it and in some ways its a very elegant solution, but I’ll need to try writing a medium-large size app before I can really comment. If the coder keeps it together and organises his components, mediators and composition carefully it could be that this works well. More on this in a later blog.

Minimum configuration & ease of coding

PureMVC involves a lot of typing. Creating a Mediator from scratch is a whole lot of hassle. Luckily for you FlashDevelop users I’ve updated some templates to work with PureMVC 2.0.3 (apologies to whoever wrote these in the first place – can’t find the URL, but will link as soon as I do!). Download them here and unzip to:

C:Documents and Settings<user>Local SettingsApplication DataFlashDevelopTemplatesProjectFilesAS3Project

However, even with templates taking away a lot of the setup work, there is still a lot of typing to do. Need to get a reference to a Proxy in your Command?

   1: var userProxy:UserProxy = facade.retrieveProxy(UserProxy.NAME) as UserProxy;

Ok, maybe I’m being pedantic, but when I’m writing a large RIA application I can imagine this getting very annoying. And my initial thoughts are that this seems to be a general theme throughout PureMVC; there is often a lot of work to do in order to get a simple task done. However, my feeling is that there will be a bunch of common tasks that will be able to be automated either through utility classes or through your IDE. And if the result of this extra typing is an elegantly structured and maintainable app then I guess its all worthwhile in the end :)

Ease of maintenance

GIGO. PureMVC goes a long way to forcing the programmer to ‘do the right thing’, but I reckon you can still end up with a mess of spaghetti if you are not careful. At this point the potential stumbling blocks seem to me to include:

  • Badly composed view and mediators.
  • Unnecessary numbers of Proxies, Commands and Mediators.
  • De-centralised logic (i.e. business logic placed in the view, which is actually possible with PureMVC)

I can easily envisage a situation where a bug arises and the developer is hard pushed to work out if it is located in the Mediator, Command or Proxy. However, I could be wrong about this and am very much looking forward to finding out myself.

Conclusion

Well, there isn’t one yet. I’ve a couple of weeks contractual work beginning next week where with any luck the client will be happy to have PureMVC let loose on their project so once I have some more hands-on practical experience with this framework I’ll be blogging something new. More later :)

21 comments

  1. Dave,

    To set up the templates you say to unpackage them in C:Documents and SettingsLocal SettingsApplication DataFlashDevelopTemplatesProjectFilesAS3Project

    Which is fine and well for XP, but I am using Vista and there is no Documents and Settings folder.

    Could you provide me the path for Vista?

    Thanks,
    Mike

  2. In your templates you forget to add “$(CSLB)” before each open brace “{“.

    I can’t get this terrible style “open brace on line”… For me it’s decrease code readability…

    Good work! Thanks! ;)

  3. For example open “SimpleCommand.as.fdt”. It have $(CSLB) only on package line.

    Rest of template should look like:

    public class $(FileName) extends SimpleCommand $(CSLB){

    override public function execute(note:INotification):void $(CSLB){
    $(EntryPoint)
    }

    }

  4. I’m using Flex Builder 3 on a Mac (Leopard).

    Can your templates be installed on Flex Builder – and if so, where?

    kind regards,

    Matt

  5. Hi again.

    I’ve looked through the documentation for Flex Builder, and I can’t find any reference to how to import templates.

    Could you confirm whether or not it’s possible to use the templates you have created for Flash in Flex Builder?

    Matt

  6. Hi,
    I just started to read about PureMVC and I found your page. I don’t understand why you are looking for low cohesion in your mvc frameworks? The traditional way is to aim for high cohesion and low coupling? Or do you mean that PureMVC is lacking high cohesion?
    Best regards,
    Patrik

  7. Hi Patrik,

    You are 100% correct, and all I can do is apologise and hide my head in shame ;) Coupling and cohesion both begin with the same two letters, its an easy mistake to make…

    Anyway, apologies to anyone who has been carrying around a skewed view of OOP thanks to this article and I have now corrected this.

    Dave

  8. Any implementation of a design pattern is not itself a design pattern. A design pattern is deliberatly de-coupled from any “official” specification of an implementation. The first problem with “pureMVC” is calling it “pureMVC”. I don’t know if there is a second problem.

  9. Well that’s ok because PureMVC never claimed to be a design pattern – it is a development framework that happens to implement a bunch of design patterns in its structure. Design patterns, whilst abstract, have to be implemented at some level other no-one would ever be able to use them for anything…

    Dave

  10. Sure. All I meant to say was that since there is no official implementation – PureMVC (apart from being called such) is as good (or bad) as any other implementation.

    I do, however, question the criticism that design patterns must be implemented. Apart from use-value being only one value, software designers can get a lot of use-value from a design pattern – without actually doing any implementation. The designer will delegate the implementation to an implementor.

  11. The best part about something like PureMVC is that you can send new developers to learn it and when they come back they’ll know how to navigate and maintain the codebase (theoretically).

    The worst part about PureMVC is how much overkill design patternage is there, if you’re not worried about hand offs with a huge codebase (ie 8000+ lines) to other developers I would write my own framework and keep it fitted to the app’s needs… It’s pretty easy to set up models, controllers, views, and create custom event classes, etc with loose coupling. Doing this might take a week to get it right at first, but in the end your codebase will probably be about 1/2 of PureMVC route.

  12. For a long time this is exactly what I did; I had my own framework developed over a number of years which worked very well and certainly required less code than PureMVC. However every now and again something would come up in a project which required me to fight with the framework to get something done and I’d end up extending the framework to cope with it. Finally I had myself a great framework to code on – and you know what? It wasn’t that different from PureMVC :)

    Its true that PureMVC applications do have a lot of supporting code, but I never actually have to write any of these by hand; I have templates for Mediators, Proxies and Commands (FlashDevelop versions available from this site), macros for common lines of code (e.g. var somethingProxy:SomethingProxy = facade.retrieveProxy(SomethingProxy.NAME) as SomethingProxy) and a PureMVC plugin to add and remove notification listeners to Mediators.

    Its true that handovers can have lots of lines of code, but I argue as to whether or not this a problem. As a developer on an existing project I would far prefer to receive a larger codebase based around PureMVC conventions in which I instantly know where everything is and how it communicates internally, instead of having to learn someone’s custom framework anew each time. Since a good chunk of the codebase is instantly recognisable as PureMVC scaffolding I just disregard that and can go straight to the important bits.

    Personally I would say the best thing about PureMVC is that it gives developers a common framework to use and (theoretically, as you say :) ) they should be able to pick up a project a lot easier than if a custom framework has been used.

    I’d say the size of the codebase is irrelevant; to me the worst thing about PureMVC is that it can encourage developers to just ‘follow the PureMVC way’ and not really think about the patterns or what they are doing. PureMVC should lay the foundations and you can then engineer your project on top of that in the best way for the app.

    This is an interesting article; I don’t necessarily agree with it all but there are some good points there – http://www.simple-talk.com/community/blogs/alex/archive/2009/03/19/72519.aspx

    Dave

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>