I was just wondering how other people working on large applications deal with the class pollution from having tons of small command classes?

Basically we don't want to be accessing proxies from mediators and would rather have all of the logic done in commands, otherwise it really dilutes the purpose of even having commands imo, I would rather deal with centralized logic.

Now saying that, how do you handle having 100s, if not 1000s of command classes in your application?  Do you try to cut them down to 10-50 core commands and then use the "type" in the command and switch off that?  I have tried this but it couples the mediator with commands a little as you have to know the type you are firing, it can no longer just be a basic registration.

I would love to hear how others solve this issue.

Cliff,

Actually PureMVC really doesn't violate it to be honest, I was just pointing out one of the reasons people do hate singletons.  While it is true that you never need to globally access the Model/View/Controller classes, you really are working with the actual objects at a global level (as the Facade is doing this).  So in my opinion it doesn't make a difference whether they are singleton or not, but to a pattern die-hard they would likely point out that the MVC classes do not need global access (as the Facade provides this) and therefore should not be singletons.

Again I'm using PureMVC for quite a large project and don't have any gripes with it, just pointing out what has been said about the use of singletons and why some people my opt not to use many of them.

PS. Great job with 2.0, I love the onRegister/Remove on mediators and the naming of them.

Ok. And how does the use of singletons in PureMVC violate this?

-=Cliff> 

I hate to be nit-picky but I did want to point out that a few of the authors of the GoF book have stated numerous times that the singleton pattern is only used correctly when it fits both of the qualifying reasons.  The first being that there should only ever be a single instance, and secondly that the actual actor is needed globally and you can expect any class to want to call on it.  I forget which author it was, but one of them has stated that it is very close to an anti-pattern (and is when not used with both rules) and wished it was not included in the book.

Cliff,

Thanks a lot I went through the Flash demo and I understand how best to have multiple views and mediators and this technique will work well.  I do have one other quick question regarding proxies.

The majority of these shared components actually use the same data and it is just filtered differently to the view by the mediator, but some of them may need different proxies.  Do you have a best practice for this as well?  If I need multiple copies of the same view/mediator (like in the HelloFlash) but with their own model proxies?

I am using PureMVC and I have some components (with mediators/proxies) that I would like to have multiple instances of at once but i am unsure how to do this.  I have not seen any examples of doing this in PureMVC as all components in examples are concrete single instances.

EDIT: Just to clarify I want to have multiple instances of the same View component, as I understand you can have multiple different views and a single mediator.

So basically I have:

[Component A ]
[ textbox        ]
[ textbox        ]
[ datagrid       ]

and also Proxy A and Mediator A that takes Component A as the argument in the constructor.  The issue is that I need many Component A's active in the application at any one time.  Obviously following any of the examples and best use cases the view is just duplicated in every instance as they share the same mediator/proxy.

Thanks.