When I attended MAX in Vegas earlier this year, I grabbed a set of these
nifty posters from the Flex team. Huge wall covering prints, there were 2 for the Flex API and and 1 for Actionscript 3. I got them back to my hotel room before I realized a) they would require extra shipping as there'd be no way to take them on the plane, and b) I'd have to take down a bunch of tapestries to make room. Oh, well.
My point is
Flex is Large. However, it is most definitely
In Charge.It is a gleaming, beautiful machine, and to contemplate what an appropriate size for such a framework should be may take some time to evaluate, because
small is relative.Unless we know the full scope of what Flex is supposed to deliver, we can't judge how much of it is superflous. And only then can we set about determining of the necessary stuff, how much is inefficiently written.
Chris' other question was
'Where's the line between a lightweight MVC framework and a couple of useful classes'. Evaluating Flex as a framwork is like the flipside of that. Where's the line between a framework and a huge set of useful classes?
I'm not knocking Flex here, I'm just saying I'm glad to be considering a much smaller question.
What is the full scope of an MVC framework?I think the answer to this is whatever it takes to help you cleanly separate your application's coding concerns into the three prescribed areas; Model, View, and Controller. Beyond that, how much is too much? Once the creepy-feature creature is on your back, it's harder than a monkey to shake off.
The chief benefit of an MVC framwork is the
frame of mind that it puts you in. Once the framework has been adopted and the project setup around it, certain mantras guide the implementor as he or she builds the system :
Keep logic out of your view by instead raising events that cause the controller to execute commands. (This lets the business logic be centralized and easily reusable).
Limit the knowledge that commands have of the view, let them instead update the model to inform the view of changes. (This lets the view be refactored easily without disturbing the business logic).
Have the model expose to commands a course-grained interface that hides the details of service and model implementation. (This allows the model representation to vary without disturbing the business logic).
The approach PureMVC is taking is that the basic architecture will be very lightweight, but provide a very flexable platform upon which to build. There will be a number of samples to demonstrate each point of interest so that the architect will have a clear idea of what functionality comes out of the box, how to subclass and use interfaces to replace or extend core functionality.
Just as the shape of the grain of sand at the center of a pearl is ultimately reflected in the pearl's outward appearance, getting the form of these core actors right is key. Getting the most implementation-time benefit (aka:
bang for your coding buck) is pretty important as well.
If you're new to MVC and design patterns in general, I'd like you to be able to use this without having to know a huge API that leaves you wondering if you've got it or not. The typical RIA developer has enough APIs to remember anyway.
If you're a seasoned architect, you'll be happy (we hope) to discover that the core concerns have been addressed in a way that you'll most likely approve of. But, you'll be free to partially override, completely replace, or totally disregard any of the core functionality without detracting from the parts that can service you well.
Once every detail has been attended to with the core actors, there are a great number of other patterns out there that complement the MVC approach and also help the architect to paint with broad strokes. They will be packaged separately with their own attendant samples that show how they can be used in concert with the core package and with each other.
This approach will allow controlled growth of additional useful patterns/actors, while keeping the number of releases to the core architecture minimal.
