4 Things To Hate About PureMVC

Previously, I have written about how puremvc takes a stand on patterns of gui architecture while Cairngorm does not. I have also proclaimed to colleagues, that I do not find puremvc especially great, but at the same time find it “good enough”, which is to be understood as: The current contenders are (were?) not any better, and puremvc solves the problem.

After using puremvc for real for some time now, I have collected a list of things, where I find puremvc getting in the way.

Here it goes…

1. Use of Service Locator instead of Dependency Injection

Two patterns for letting a software components resolve its dependencies on other components are Service Locator and Dependency Injection. Of the two, puremvc use the Service Locator pattern, which I like the least. As an example, let us take a simple command:

public class ExampleCommand extends SimpleCommand {
  override public function execute(note : INotification) : void {
    var clientDataProxy : ClientDataProxy = facade.retrieveProxy(ClientDataProxy.NAME) as ClientDataProxy;
    clientDataProxy.getExampleData();
  }
}

What this command class does, is to ask a service locator (the facade.retrieveProxy call), through a direct dependency on the puremvc api, to get an implementation of a ClientDataProxy service. Next thing is to call actual services on that proxy.

Here is how I would like it to have been:

public class ExampleCommand extends SimpleCommand {
  [Inject] private var clientDataProxy : ClientDataProxy;
  
  override public function execute(note : INotification) : void {
    clientDataProxy.getExampleData();
  }
}

There is no code here, that looks up the service. There is only the usage of the service. For one thing, the service lookup code only clutters up the code, as it has nothing to do with what the application is doing. Another thing is the direct dependency in the puremvc api to lookup the service. Both are things not welcome in the code.

2. Casting, Casting, Casting

Again, taking a line from the example above:

    var clientDataProxy : ClientDataProxy = facade.retrieveProxy(ClientDataProxy.NAME) as ClientDataProxy;

Wow! I am writing the type again, and again, and again. All the retrieve calls in puremvc have rather wide return types, hence the need for all the casting.

And it is not only the retrieval of proxies and mediators, that needs casting to specific types. It is also when extracting data from the notifications. Like this:

   var user : User = notification.getBody() as User

This is partly because AS3 has no generics/templating system, partly because of puremvc design (notifications are not application specific classes) and partly due to the use of service locator and not dependency injection.

Anyway, it is damned irritating.

3. Forced Inheritance Everywhere

Anywhere I go, I need to inherit a puremvc base class. This is hard to cope with, in an OO programming world which have long gone to favour composition over inheritance. Especially in a single inheritance only language. To me, it seems like puremvc was designed for the inheritance to provide two things:

  1. Having mediators, commands and proxies hook properly into puremvc, but overriding methods like, listNotificationInterests(), execute() and call super constructors.
  2. To provide access for the appliction into puremvc glue, primarily by letting sub-classes access the facade everywhere, hereby giving access to the service locators to obtain mediators and proxies.

Now, both of these can be accomplished in other ways, if the framework had been designed in other ways.

4. Avoids Platform Dependencies

At first glance, avoiding platform dependencies for a framework might look like a positive thing, but it is not. At least not from the perspective of the user.

So, what do I mean by platform dependencies? Well, puremvc is written purely in ActionScript, and then ported to other languages like C#, Java, haXe, PHP, .. you name it. To be able to port the framework nice and easily, there can be no direct dependencies on flex and flash APIs.

Think about that for a while…

This means the framework cannot tell about what it is doing using the flash trace() method. I suspect this to be the reason that there is no debug option to turn on in puremvc. It also cannot utilize flex or flash event classes. I suspect this to be why notifications, a completely new abstraction found in puremvc, was conceived, instead of just using the event framework.

Each and every time there is a very platform specific feature, the core framework is unable to utilize it, as that part would then be impossible (or damned hard) to port to another platform.

But for me, the application developer, I have no need to port the puremvc framework. I have chosen flex. I am writing an application for flex. I am using the flex APIs/components, hereby binding my application to the flex platform. There is then no gain, only pain, in using a framework, which completely abstracts out that chosen platform.

Then What?

Is puremvc bad then? Hell no! Let me reiterate: Tt gets the job done. It solves the problem. Which problem? The problem of keeping an architecture on your code! You get a split-up of view, model and application logic. Shelves to place you code on.

I just think it could be done better.

Back when I started using puremvc, it was “the best” around, as I saw it. But others have come to. Most notably, Mate has had some great press lately. I think it is great, but also think it has drawbacks.

October 5, 2008 · polesen · 22 Comments
Tags: ,  · Posted in: Design, Programming, Rich Internet Applications

22 Responses

  1. Marty Pitt - October 6, 2008

    I agree completely, with the exception of the casting, which — IMHO while painful — is not really a failing of the framework, but instead the language.

    At a previous project I ended up refactoring all the core classes in the framework to use composition rather than inheritance. The fact that Mediator subclasses Notifier is unnecessary, and makes testing difficult.

    We also made a blanket rule that facade.retrieveX() was forbidden in any code except Commands, to avoid tightly coupling objects together. (At the time, we weren’t able to use a DI framework, which would’ve been preferable as you mention).

    We found that using the facade.retrieveX method creates dependencies similar to being dependent on a singleton — the amount of setup code for a unit test becomes very heavy very quickly.

    Great post!

    Marty

  2. julien - October 6, 2008

    Interesting post.

    I still find PureMVC much more object oriented and flexible than other frameworks, as for the “over casting”, well I just think (correct me if I’m wrong, I want to learn) it comes from the fact that lots of stuff in PureMVC is based on interfaces (I see it as a good practise) and quite “abstract”. However, personnaly, I’d say Cairngorm or Mate are much more “strict” when it comes to using them in your code … And well your previous post on Mate almost made me think I should never use it

    Cheers

  3. 4 Things Bad About PureMVC - October 6, 2008

    [...] Per has another post to take a in-depth look at one of the ActionScript based framework, PureMVC. This time the post listed 4 things he hates [...]

  4. Raleigh - October 6, 2008

    RE: #1 – How would this work for multiple instances of the same proxy class?

    For example, I recently had a project that used multiple instances of a simple XML data proxy class, each created with a unique name and XML file URL. Each worked exactly the same, just loaded different data.

    It looks like the method you talk about would require a single instance per class, or am I missing something? I’ll admit, DI is a relatively new concept to me.

    Thanks.

  5. polesen - October 6, 2008

    @julien

    …as for the “over casting”, well I just think (correct me if I’m wrong, I want to learn) it comes from the fact that lots of stuff in PureMVC is based on interfaces (I see it as a good practise) and quite “abstract”…

    I do not agree! In the case of a retrieveProxy call on facade, it is true that the return value is IProxy–an interface. But, to utilize that value, I would either have to (a) call getData() on it and get an Object instance, which I would then have to cast, or (b) cast the IProxy instance itself, to get access to call some of the methods on it. This is what comes with using type-safety in AS3.

    BUT: If the framework itself had been designed with injection instead of with some more generic service-locator mechanism, I would not have to cast. I would have the correctly typed instance available.

  6. polesen - October 6, 2008

    @Raleigh

    How would this work for multiple instances of the same proxy class?

    It would not :-)

    Or, it could be made to. I am not quite sure how deep the metadata support in AS3 goes, but if an annotation like this one:


    [Inject("PROXY_NAME_HERE")]
    private var clientDataProxy : ClientDataProxy;

    is retained in the bytecode after compilation INCLUDING its parameter, there should be no trouble to implement injection of the same proxy type, but with different names, inside a framework.

  7. Theo - October 6, 2008

    One word: overengineered.

    I find PureMVC almost offensive in its invasiveness. I do not agree with those that think that PureMVC is a good example of object oriented programming, quite the opposite, to me it looks more procedural than anything. The focus on global variables and centralized event dispatching, are two examples of this, but the inflexible types that require you to cast all over is also a sign of bad, non-object oriented design.

    And don’t get me started on the portability issue, why on earth would I want to trade the power of my platform of choice for portability? My application code is not portable, so why care if the framework is portable? I don’t choose application framework first and platform second. I choose the platform because it has the features I need to get the job done — to then choose an application framework that denies me full use of those features would be nothing short of stupid.

    If you have any argument for the benefits of PureMVC’s portability, please post it here: http://stackoverflow.com/questions/143403/how-does-the-portability-of-puremvc-benefit-the-application-developer

    I use Mate and my application code has zero dependencies on the framework.

  8. JasonMacdonald - October 8, 2008

    So by your estimate, PureMVC should work with Flex and nothing else because you want to use Dependency Injection? And screw all the Flash/AS3 only users out there? Or maybe they should completely rebuild the framework into two separate branches (or 10) for accomplishing the same thing? That’s productive.

    Why don’t you stop complaining about how all the frameworks out there have it wrong and BUILD YOUR OWN. Save the rest of the world from your complaining how everyone else gets it wrong and you are right. I honestly can’t stand people like you. Nothing but complaints all the while you do nothing to contribute to the end goal.

    If you don’t like it, don’t use it… it’s that simple. If you like it but think it could be improved, contribute! Don’t just bash it for the sake of some blog views.

  9. Theo - October 9, 2008

    @Jason (although it was perhaps not directed at me?)

    Since PureMVC is touted as a Flex application framework, among other things, I think it’s fair to criticize it for being bad at it. It’s probably not as bad for pure ActionScript applications, but that’s just because it’s less limiting for those.

    Since one of the fundamental ideas behind PureMVC is being portable, then I think it’s fair to criticize it on that point — for example by saying that it’s a pretty useless feature.

    Since many think that PureMVC is a good application framework for Flex application development, I think it’s fair to criticize their reasons for doing that, if I can make a case for it that is on a higher level than “you are stupid”.

    It’s definitely not as simple as don’t use it if you don’t like it. You can hate five parts of something while still using it because of the overall benefits. Pointing out the problems leads to progress, asking dissenting voices to shut up leads to the opposite.

    By the way, Luke Bayes and Ali Mills have released a fork of PureMVC called FlexMVCS: http://www.asserttrue.com/articles/2008/07/15/flexmvcs-released It gets rid of the most annoying anti-Flex-isms, and the worst architectural issues.

  10. JasonMacdonald - October 9, 2008

    My comment was directed at the writer of this blog and the fact he seems to do nothing but complain about every framework instead of either (a) contributing to help relieve the “problems” or (b) build his own and share with the rest of us his vision of the perfect framework. I suspect he would dislike having people tell him his framework sucks because of some decision he had to make in building his utopia framework. The fact of the matter is NO framework is perfect in everyone’s eyes. I challenge you to build one that is, I’ll use it!

    Theo, I have no problem with you disagreeing with the way PureMVC is implemented in the Flex context however it would be more beneficial if you also proposed a solution rather than just parroting the perceived deficiency.

    And yes, my comment of, “if you don’t like it don’t use it” is that simple. Or a better one would be, if you like it but find some issues with it, help make it better! If all you’re going to do is whine and complain that something sucks, and do nothing to help, then please do sit down. You aren’t helping.

    Calling the feature of portability “useless” I think is very short sighted. If you don’t ever intend to switch platforms then I agree it’s probably a less desirable feature for YOU and a platform specific framework might be more desirable for YOU.

    However, for myself, and others I’m sure, the ability to learn one framework and use it across multiple platforms outweighs the small benefit of using platform specific features in the framework itself. Right now I’m forced to develop in AS3 only because the Flex framework is simply too large in file size for my app. However, when the time comes that Flex is either optimized in DL size, or the entire world has the framework cached locally, I’ll most certainly port my whole project over to Flex. And when I do I’ll have very little code to rewrite AND I won’t have to learn yet-another-damn-framework.

    Then there’s always things like Flash lite. What happens when my company decides they want a version of our app on mobiles? Learn another framework? How about a desktop version using AIR? Rewrite my code again? How about my back-end in another language (PHP or Java)?

    That’s now 5 platforms I could use for one app and 4 frameworks I didn’t have to waste months learning and rewriting my app for. That is the power of PureMVC to me. Not whether it is the absolute best solution for each platform but rather the time savings across ALL of the platforms I can, and will, use.

  11. Theo - October 9, 2008

    If you don’t like his blog, don’t read it… it’s that simple. If you like it but think it could be improved, contribute! Don’t just bash it for the sake of it.

  12. polesen - October 9, 2008

    Greetings, McDonalds JasonMacdonald

    I shall try to completely ignore you getting personal, and instead try to extract some of your actual arguments about the post and about puremvc.

    When you say:

    .. So by your estimate, PureMVC should work with Flex and nothing else because you want to use Dependency Injection? ..

    No. I would not dream of trying to impose that on puremvc, as that would go against the main design goal of puremvc.

    …If all you’re going to do is whine and complain that something sucks, and do nothing to help, then please do sit down. You aren’t helping…

    Obviously, I disagree. I actually believe I *am* helping.

    Helping is the main point of this post. Not help in the sense of changing the framework. But help people choose a framework that suits them. I myself find it hard to choose a framework for a platform. It is not until you have actually worked with a framework, you discover the real pros and cons of it. I myself would have liked to read a post like this good one, before choosing puremvc. I might very well have choosen it anyway, hey, I might even choose it again.

    Now, that said, both Theo and I seem to disagree with you on how much of a value-add the portability of the framework is for the user of the framework, as opposed to the value-add of having platform specific features in the framework itself.

    When you write:

    The fact of the matter is NO framework is perfect in everyone’s eyes.

    You are actually quite right and spot on there. That is also why this is a good post. This post, together with the comments, helps possible newcomers to the flex world, to evaluate if they want to use puremvc or not.

  13. Joel - October 9, 2008

    @Theo
    “By the way, Luke Bayes and Ali Mills have released a fork of PureMVC called FlexMVCS: http://www.asserttrue.com/articles/2008/07/15/flexmvcs-released It gets rid of the most annoying anti-Flex-isms, and the worst architectural issues.”

    This is the underlying beauty and architectural strength of the framework. It is simple, generalized and easy to manipulate to your specifications. When I am writing in Flex, I extend the base patterns to conform to my needs for the application. When I am writing in AS3, I do the same. Now I have a library of useful utilities to develop with.

    “for example by saying that it’s a pretty useless feature.”

    It is a useless feature… to you. Coming from the perspective of somebody that writes applications in using the Flex framework, pure AS3, and Python it is nice to have a similar context across all three approaches. When I look at a PureMVC Python application it is instantly clear what is going on. I’m sure the folks using PMVC in AS2 appreciate the efforts as well.

    As much as I love Flex, when I want a widget, tossing the framework overhead onto the file for no good reason is depressing (almost offensive?). The ability to use a similar framework and shared model layer without the burden of additional frameworks is very useful.

    While entitled to an opinion, I think by the definition of the term useless, this particular one is incorrect.

    Looking over your Mate examples, I really appreciate that effort (Mate looks like something I want to add to the toolbox). Your Cairngorm critique still has me nodding my head in agreement, but I disagree on the PureMVC hate, if for no other reason than it has been incredibly useful to me.

  14. Theo - October 10, 2008

    So, let me clarify what I mean when I say that the portability of PureMVC is useless (although, of course, YMMV). Some of it may be a repetition of what I said above:

    I choose a platform because it has something that other platforms do not. If I’m creating an RIA I choose Flex, if I’m creating a animation-heavy web site I choose Flash, if I’m creating a text-heavy web site I choose PHP, Rails or some other backend technology. After having chosen the platform I choose the tools, and I want tools that let me harness the powers of the platform, that help me use the features of the platform to their limits.

    PureMVC isn’t that tool ever. By design it takes away some platform-specific features — it doesn’t stop me from using them completely, just it makes them significantly less powerful (bindings and event bubbling are two examples in Flex). PureMVC is never a good fit for a platform, because it takes a least-common-denominator approach.

    The other argument is that you as a programmer get more productive by using PureMVC since you can use your knowledge on other platforms. It may be true when switching from ActionScript 2 to ActionScript 3, or from either of those to Flash Lite, or other Flash-based platforms, but they are more or less identical anyway. The languages is very similar, the API:s are very similar, the runtime is similar, the execution style is similar, etc. I don’t think that it’s fair to use AS2 and AS3 as examples of changing platforms, they are too similar (but if that’s the platforms you are switching between, then good for you).

    Looking at the list of platfoms that PureMVC has been ported to there are such extreme differences, PHP and ActionScript 2, for exampe, have almost nothing in common besides being programming languages. They run on platforms that have extremely different execution models, their API:s are two different worlds. Same for C# and Perl, or Ruby and ColdFusion, and so on. AS2 to AS3 I do understand, but even AS3 to Flex is questionable.

    The application framework is such a tiny thing compared to the differences in language, API, execution style, runtime peculiarities, that is why I find PureMVC’s portability utterly useless.

    Joel mentions that when looking at a Python PureMVC application it’s instantly clear what is going — but isn’t that just because someone has written an ActionScript application in Python? I mean, you can write Fortran in any language.

    By all means, use PureMVC for AS2 and AS3 applications. I have issues with the design of the framework (besides my other reservations), but I don’t know of any better. You may even say that being able to use the same framework in both AS2 and AS3 applications is helpful to you, and I won’t disagree. But you can’t go from there to saying that PureMVC being portable to any platform is useful, or that it says something about the usefulness of the framework on that platform. I’m sure I could port WordPress to Flex, but it would most definitely not be useful.

  15. Joel - October 10, 2008

    >>By design it takes away some platform-specific features — it doesn’t stop me from using them completely, just it makes them significantly less powerful (bindings and event bubbling are two examples in Flex)

    I don’t really understand this, and perhaps that is just my ignorance, but I use both bindings and event bubbling heavily in my pureMVC flex applications with great success. I’ve never once felt that I was losing anything from the Flex framework, or felt the need to say “Damn, I sure wish I could use ________ right now, but PMVC is totally restricting me”

    >>isn’t that just because someone has written an ActionScript application in Python?

    No, it is because outside of the API of the language the patterns in play are the same.

    The portability of PureMVC is a side effect, not a stated goal. The reason the ports exist at all is because other people have found them useful, and have therefore contributed their time and effort to make them so. They are not there as an exercise in mental masturbation, stroking the ego of a framework designer.

  16. Software Pills » Se busca sustituto de Cairngorm - October 16, 2008

    [...] http://www.techper.net/2008/10/05/4-things-to-hate-about-puremvc/ se describen algunos otros [...]

  17. PabloBandin - December 1, 2008

    >>Use of Service Locator instead of Dependency Injection
    Heee… no? commands are created based on an Notification, witch create a new instance of the associated command… The singleton Controller dosent known anything about the implementation of the command. Using a Dependency Injection pattern will make you write more code in order to make the controller inject the apropiate Proxy instance to the command. Service Locator avoids having the controller knowing too much about the implementation of a command.

    >>Casting, Casting, Casting
    The singletons in the framework let you use them as storage base for your concrete implementations of Mediator, Proxy and Command… the only way to do this is using interfaces. I think is not a big deal.

    >>Forced Inheritance Everywhere
    Mmh… in order to work well, the singleton Model, View, and Controller uses interfaces of IProxy, IMediator and ICommand. You extend them to implement it’s interfaces and create custom methods… this inheritance is what let you work with the framework.
    Composition over inheritance is recomended ONLY if the implementation of the component’s interface is short and easy to recode. Using composite in a Mediator, Proxy or Command will brake all the internal code that these classes use to register itself with the other singletons.

    >>Avoids Platform Dependencies
    This is a design decition. But it dosent restrain you to use platform specific API, come on! lol, what are you doing?

    >>I just think it could be done better.
    Mabe if you give an example… instead of just talking… ^^

  18. polesen - December 1, 2008

    @PabloBandin:

    commands are created based on an Notification, witch create a new instance of the associated command

    Yes, exactly. And as puremvc insist on being the one that create the command instances, and at the same time supports no injection as part of the framework, I cannot get injection.

    The singleton Controller dosent known anything about the implementation of the command

    Nor would it need to.

    Using a Dependency Injection pattern will make you write more code in order to make the controller inject the apropiate Proxy instance to the command

    That is not true. But the framework code might become larger. A trade-off as a framework user I would like, if that made the code of the application more clear with less clutter.

    Using composite in a Mediator, Proxy or Command will brake all the internal code that these classes use to register itself with the other singletons

    I think you misunderstand me or maybe I haven’t been clear enough. I do not want to compose a command inside my own class, and dispatch methods to it. I would simply like to be able to create commands, mediators, proxies without being forced to inherit. With the current implementation, I am forced to.

    This is a design decition. But it dosent restrain you to use platform specific API, come on! lol, what are you doing?

    It should be clear, but to answer your question: “I write flex applications using puremvc”.

    It is in the original blogpost above, but I feel the need to repeat myself here:

    This means the framework cannot tell about what it is doing using the flash trace() method. I suspect this to be the reason that there is no debug option to turn on in puremvc. It also cannot utilize flex or flash event classes. I suspect this to be why notifications, a completely new abstraction found in puremvc, was conceived, instead of just using the event framework.

    Each and every time there is a very platform specific feature, the core framework is unable to utilize it, as that part would then be impossible (or damned hard) to port to another platform.

    I know it does not restrain ME from using platform specifics. It restrains ITSELF from utilizing the platform specifics.

  19. shaun - June 1, 2009

    “I just think it could be done better.”

    So do I. Here is my attempt at solving all the problems you have outlined:

    http://shaun.boyblack.co.za/blog/2009/04/16/robotlegs-an-as3-mvcs-framework-for-flash-and-flex-applications-inspired-by-puremvc/

  20. shaun smith » RobotLegs Updates, Demos and Unit Testing - August 1, 2009

    [...] developers really dislike PureMVC (probably for many of the same reasons that I started RobotLegs in the first place) and so [...]

  21. Murray - November 17, 2011

    I have just rewritten the Cafe Townsend sample app which comes with pureMVC first using Parsley then using RobotLegs, then using RobotLegs and as3-signals, as an exercise in illustrating how to create unit tests with these frameworks as well as pureMVC itself. I have several big problems with pureMVC over and above the platform portability issue discussed in length above. These are

    1) pureMVC requires a lot of code to wire it’s pieces together, registering mediators with the facade, retrieving proxies from the facade, etc. DI frameworks do this more concisely, and in well known places – contexts. In pureMVC this bootstrapping logic can be scattered.

    2) I don’t like the fact that though it’s an MVC framework, I have to develop Mediator, Proxies and Commands which don’t semantically map to Model, View and Controller. Where exactly is my business logic going? It’s not immediately clear and I find because the framework interposes itself everywhere in your code it is difficult to clearly pick out where particular business logic resides, and I get confused as to where I should be looking. Maybe I haven’t been using pureMVC in anger enough, but who wants a steep learning curve and to have to use something in a counter intuitive way?

    3) pureMVC code is hard to unit test because of the invasive nature of the framework throughout the codebase. An opensource framework for facilitating unit testing exists (http://code.google.com/p/puremvc-flexunit-testing/), but an overarching problem is that because there’s a whole lot of code you need to write to bootstrap the framework, do you unit test this code? Probably not. You would thus end up with lower code coverage than could be obtained using other frameworks.

    My favoured frameworks these days are DI frameworks: Parsley using the Presentation Model pattern and RobotLegs, also using the Presentation Model pattern in combination with the as3-signals framework.

    Parsley is a heavy weight DI framework which uses metadata tags and a context generally descibed as an mxml file, though it can also be created programmatically. The programmatic form of context creation lends itself well when you need to bootstrap Parsley with relevant classes in unit tests and the Presentation Model pattern is very easy to understand and implement, and is easier to get to grips with than pureMVC jumble of mediators, proxies, commands mapping on to Model View Controller. In the PM pattern, all your presentation logic is in the PM, your View should ideally just be MXML components which bind to variables and methods in the PM. The PM can then be injected by Parsley to the view and itself contain injected dependencies to services, etc. No need for lengthy boilerplate bootstrapping code, it’s all driven off metadata [Inject] tags.

    RobotLegs is a lighter weight DI framework which requires you programmatically wire up your mappings. Mediators and Commands also make an appearance in RL as do [Inject] tags, and typically in a Mediator you will have to implement the onRegister method where you have to map Events you are interested in to the methods which are called when those Events are fired. The Mediator will also have a View reference injected into it and control its behaviour throught this. It is possible to eliminate the use of as3 Events with RL using the as3-signals project, and also to eliminate the use of Mediators by using the Presentation Model pattern in combination with as3-signals.

    I would strongly recommend anyone thinking of using pureMVC to take a hard look at these other frameworks as they are frankly easier to use, less verbose and lead to cleaner seperation of concerns.

  22. jboogie - March 18, 2013

    isn’t it obviously an oxymoron to call a third party swc “pureMVC”? if you were doing pure MVC you would just make a Model, View and Controller and not have to use a third party swc. so obviously it is just about wanting “dependency injection” but the action script virtual machine requires all class definitions in its import statements and compiles all the classes anyway so “dependency injection” in actionscript is nothing more than guys trying to be hip or lazy or pretend to be smarter than they really are. if you can’t do it with just as3 and some basic design patterns then your programming is weak. overarchitecting is only going to compound your problems and invariably you are going to end up with a huge pile of crap which a guy like me is going to have to drag to the recycle bin and rewrite your whole application – only now the deadline is going to be around the corner and i will have to develop the whole thing in 1.5 months that you screwed up for 8. true story. just use flex, as3 and MAYBE one or two and never more than three design patterns. more than that and it just means your basic coding is weak.