Im not a flex developer but have been building flash applications now for some time and like you spent much time learning about as much as possible , and then also creating my own workarounds. I reached the realms of reading up about design patterns in the beginning of last year and am still growing my own personal practices with all the knowledge obtained. I see you feel very strong about the points mentioned above but also you seem open to discussions or a choice disagreement, So Im going to disagree with you on point 1 and point 2 and also reference the last point of concern by Darrens response to your post. Firstly there are many arguments pro and con about singletons all over the web , these debates extend to further debates within each pro or each con with even finer smaller dogmatic ideas or personal rationalisations towards each matter of concern, I personally found myself jumping to one state of belief for a time and then totally going another direction after that .. but all this had to happen while I am employed at a new media agency where there main point of concern is turn around times. What this situation has brought about after 5 years of push and pull is finding a perfect balance for both worlds. I achieved this by constantly re-factoring / rewriting my code library and ideas over and over and over again. I now have an AS2 / AS3 framework that has exactly the same syntax for use from the API point of view , how big is the framework?? its not big .. point! It comprises of the very basic building tools needed to put together (quickly) any RIA. It uses a central event dispatcher(point 2) which i named a communicator and does not suffer from your quote ” both apps responding to each other’s events. Oh noes!” scenario ever. It also uses a singlton for this (point 1) and functions perfectly in any actionscript environment I dont want to let this response get to long winded , so to sum it up , Just as all flash objects extend from Object , I have one class named AbstractController , which creates/registers its scope to the central communicator, and all my framework objects be they bussiness logic or view controllers extends this class except for VO's or DTO's. As Darren mentioned about all the extra effort to make uber reuable / scalable frame works is not always practical , and quote wikipedia on IoC http://en.wikipedia.org/wiki/Inversion_of_control : “There are in the end five classes needed to switch a lamp after pressing a button” or “macaroni code[citation needed] (in the extreme: methods with only one line of code that merely act as gateway to the next layer).” as you can see .. I eventually decided Im not sold on this matter of extreme design pattern coding mayhem because in conclusion , 90% of the time , the real world implementation of whatever im going to build never needs it. what I found I (and my employer and our clients) need the most is… TIME! So I keep to my simple yet very extendable small RAD framework concept now and build classes that buy me time with mundane tasks like buttons , xml pagination , animation effects etc..

No, I assume that most of the view components that I mediate have been thoroughly tested elsewhere. The idea with the Mediator pattern is that your view components are stand-alone and portable. If we’re talking integration testing, then I *could* test my Mediators with mock view components. Most of the time, however, I’m more interested in testing my application (models, services, commands) than my view.

How do you test your view then if you don’t use Presentation model?

Greg