Best use of framework events in application architecture

Question

Hello,
I apologize in advance if this is not the appropriate forum to be posting about Flex framework questions.  I considered the Cairngorm forum, but thought the question applied more broadly to all flex frameworks. That, and it seems that the Cairngorm forum isn't really very active.
My question is about using frameworks for application architecture. Reading the "Introducing Cairngorm" document,  I see that it specifically says that Cairngorm events are just those events that will handle business logic (things like grabbing data from a server, committing data to a server, etc).  So then, how does a view interact with a controller when changing state?
Let's say I have two or three different views of the same data and I have a buttonbar to switch to the view I want. Is it then typical to dispatch a Cairngorm (or Mate/Swiz/Pure MVC, etc..)  event to the controller to change the view state of the application?  Does this effectively mean that for every button a user can click on, we'll have an event and a command associated with that event to perform some change of state or business logic? With a moderately complicated application, with several different screens, a few forms, a couple of lookups, i.e. lots of buttons for user input, that seems like an awfully huge number of events/commands...? Or do you dispatch a regular old flash Event to handle this? Or does the view data bind to the model to change the view state?
Obviously there's never any single correct answer to application architecture questions, but I'd like to know if there's any general best practices that I should follow. I don't want to under-architect OR over-architect my app.  I'm new to Flex programming and would like not to code something egregiously ugly.
Thanks,
Cory

Answer 1

Hi,
Consider this, there is no such thing as an enterprise level RIA, the whole concept behind thin client was to restrict the enterprise requirements to the backend, that being said if we assume that a flex application is specifically for the client end and can maintain its own state and that MVC frameworks are more about enterprise solutions then the whole framework argument becomes what it is, academic BS.
<start rant>
Its really simply, in half a century nothing has changed, you have rules and requirements(model), you have access to that(view) and you wrap it up as a program/application(controller) so  why do you need convoluted multilayer abstraction of functionality to make things work ? maybe so those that can't get a real development job can run around and preach at conferences, how else could they feed their adopted kids.
So all those nice buzzwords, design patterns(the new age terminology for modular architecture), model/view/controller, borg coding(resistance is futile) is all very fine if you want to act smart but producing quality code actually means you are smart. As you may have guessed I am not a strong proponent of MVC frameworks, and I don't even need to get into the argument that everytime a 'framework' expert gets control of a project that isn't done in their MVC  poison of choice it gets a rewrite, clients really love those associated costs and retesting requirements.
</end rant>
You only need 1 framework for flex and thats the flex framework.
Have a read this blog, the section on MVC and Flex is very interesting if not overly polite.
http://www.herrodius.com/blog/216
David