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

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.

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.

Dave

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