The best Flex MVC framework

08.31.2008

UPDATE: Since the writing of this post, I’ve converted to and fully endorse Robotlegs as my MVC framework of choice. I invite you to check it out. Even so, the content of this post still remains relevant.


There isn’t one.  At least not for everyone.  That’s the bottom line and hours of googling won’t change it.  I’ll explain what I mean–but first, here’s a real intro:

If you’re not acquainted with what MVC is and are interested in learning more, I’d recommend starting off with Wikipedia’s Model-view-controller entry.   Simply put, MVC is a pattern of keeping portions of code where they belong, especially when it comes to code dealing with the model (data), view (user interface), and controller (operations/communication).  While MVC can simply be a development process or how a developer thinks while creating an application, communities of developers have often formed frameworks, or basic code structures, whereon a developer can base his/her code when creating an application.  They’re not always necessary, but many developers have favored frameworks because they help enforce good coding practices, eliminate “boiler-plate code” (repetitive code needed in each application), and create standards whereby developers can easily catch up to speed when joining a new, unfamiliar project.

With Flex, it seems there are more MVC architectures than there are developers.  There are plenty to choose from and their implementation can vary widely.  With so many frameworks, the inevitable question seems to always pop up: Which is the best one?  To truly find an answer, you have to consider who’s asking the question.

For a great illustration of this point, take a look at Cairngorm, the most widely-used Flex MVC framework.  It’s supported by Adobe so many developers naturally gravitate toward it.  It also uses, by most accounts, great programming principles.  By great principles I mean the ones you might learn in a programming theory computer science course.  And just as you might expect for feedback from students in a programming theory course, you can expect similar responses from developers who use Cairngorm.  Most of the time, such developers appreciate the fact that such a framework exists and that it promotes good coding principles.  However, if you ask them if they actually enjoy developing with Cairngorm, you’ll usually hear a an animate “no.”  Why?  Because theory does not always mean practicality or productivity.  This is even more true when dealing with projects of varying complexity, timeframe, maintenance, and team size.

The most often-heard complaint about Cairngorm is that it requires too much code duplication.  For most development teams (including my own,) this is certainly true.  The various layers, from the Cairngorm events, to the controller, to the commands, to the delegate, require a lot of code duplication for little gain…for us.  For those with large systems, heterogenous backend services, high employee turnover, long-term maintenance, or other such attributes (what Adobe consultants might be dealing with,) such a framework may be exactly the ticket.  When it comes down to it, your choice of MVC framework should come down to what drives your bottom line, not what others consider to be good theory or what works for them.

Because of this disparity in needs vs. fulfillment, each MVC framework is going to have a bucketload of both good reviews and bad reviews.  Some frameworks may be better than others at solving problems for the greatest number of developers.  In such a case, ask yourself if a good generic solution is really better than a not-as-good customized solution.  What may be “not-as-good” for others may be exactly what you need.

Many other questions can help pinpoint what you’re really looking for in a framework.  Does one framework have a strong following that will fix bugs and implement functionality when needed?  How much is this development community worth?  Is the framework too heavy for your application’s simple needs?  Can your application really take advantage of a large number of code layers or does it make sense to cut out the plumbing?  How difficult will it be for new hires to grasp the application’s architecture?  Are you handing the application off to a team that’s acquainted with a specific framework?  Are your developers skilled enough to recognize when they’re writing spaghetti code or do they need strong guidance and tight restrictions from the get-go?

To sum up and repeat what I’ve said before, there is no best Flex MVC framework.  First determine what your development team really needs and then find the framework that best fulfills those needs.

So you may be wondering what my team over at Rain chose for our MVC needs.  After researching and evaluating Cairngorm, PureMVC, Mate, Guasax, and Fake, amongst others, we decided to go with a solution built in-house and customized for our needs.  It’s based off Cairngorm with a couple layers cut out as well as a few features tossed in (such as undoable commands.)  Good luck on your quest to find “the best” Flex MVC framework!

Tags: , , , , , , , ,


Comment

12.01.2008 / AaronHardy.com :: For all your Aaron Hardy needs. » Blog Archive » Meta-Learnings from Adobe MAX 2008 said:

[…] Flex microarchitectures/frameworks are like punk trends.  A decade ago, the trend was baggy jeans, cushiony shoes, and spiky hair.  I liked and still like most of the those trends for comfort and skateboardability.  Now it seems punks are having a hard time differentiating themselves from themselves.  They can barely fit in their pants, have their hair slicked over their eyes, and are back to paper-thin Converse Allstars.  Flex microarchitectures have similar trends.  It used to be that everyone was all gung-ho about them.  They loved em and thought they were cooler for having more than three on their resume.  Now you’ve got a bunch of people saying, “Nah, they suck….I don’t even need them…and you suck for using them.”  As with the punk trends, I sit in the middle. […]


Leave a Comment

Your email address is required but will not be published.




Comment