Home >
I use frameworks in my Flex code, and so should you. There is some debate today about whether there is any utility in using frameworks in Flex. The argument against frameworks is generally that they are unnecessary, constrain development style, and add lots of useless overheard to applications. I use frameworks in my Flex code because I want my code to be as valuable as possible, because I want to be as profitable as possible. Can I program in Flex without frameworks? Absolutely. I can also program in AS3 without Flex. Frameworks, whether the Flex framework or a framework on top of Flex, are worthwhile because they make programming faster, make my code more maintainable, and encourage adherence to best practices like decoupling and encapsulation.
Programming speed is one of my biggest motivations for using frameworks within Flex. In almost every case I could come up with a more efficient system if I devise an application specific framework. And if I were working on a product developed over years, it might be worth it. But the reality is that most Flex work is done on a contract basis spanning weeks or months. There simply isn't time to create a new framework for every application. Additionally, most Flex applications focus on the richness of the user experience, not the overall speed efficiency of the application. When a company is deciding where to spend their money developing a Flex application, they can't justify taking the time, and therefore money, to develop an application specific framework. The ROI on an optimally efficient Flex application is not significantly higher than a somewhat less efficient Flex application. Also, finishing projects quickly is an advantage from my perspective as well. If I can commit to a project for 3 months rather than 12 then that single project represents less of my total business. That means if something goes wrong with that one project it has a significantly lower impact on my bottom line. I use standard frameworks because they let me achieve acceptable results much faster which is an asset for my clients and my business.
Standard frameworks make my code easier to understand, modify, and reuse. If I've written my code without a standard framework and hand it off to a new developer then that new developer is going to have to spend time figuring out how I structured and architected my code. I could provide a manual describing my system, but that only moves the extra time from the new developer to me. If I stick to a standard framework then a new developer can take over and know exactly where to look for things and how to modify my code to add or change functionality. By using a standard framework, I increase the likelihood that my code will continue to be useful well beyond the scope of the initial engagement rather than being scrapped by the next developer. I use standard frameworks because they make my code useful for a longer period of time, which makes my code more valuable, which makes me more valuable.
Finally, using a standard framework forces me to adhere to certain best practices. Before C++, there were programmers who were correctly structuring their C code so that it adhered to the principles of encapsulation, abstraction, and decoupling. But it was difficult and far more common that programmers violated these principles. When classes were added in C++, it made it easy to program well, so more people started to program well. There are still people who write bad code in C++, but it is less common than when C was the standard. In the same way, a good programmer can program well in Flex without another framework. But, its difficult. Using a framework makes it easier to program well which makes the lives of good programmers easier and makes it more likely that more people will program well. And when code is written well it is generally more efficient, easier to maintain, and less likely to have bugs. I use standard frameworks because they make it more likely that my code will be well written and that any developers working with my code in the future will write their code well, which makes my code less likely to produce bugs which makes it more valuable.
The naysayers are right, using standard frameworks in Flex does make my Flex code less efficient. However, that rarely ever affects the business value of my programs enough to offset the cost of not using a standard framework. Some great work has been done without using frameworks, and in certain situations I think that not using a framework is the right call. Typically these are situations in which development is going to be ongoing for an extended period of time and efficiency is a major goal of the application. For all other scenarios, if you're not using a standard framework you're probably not achieving your highest business potential.
Interested in learning more about Flex frameworks? I'll be moderating a panel discussion about Flex frameworks at MAX at 4:30PM on October 6th. We'll have a panel of developers discuss the strengths and weaknesses of Mate, PureMVC, Swiz, and Parsley.
Tag Cloud
Podcasts & Screencasts
@InsideRIA on Twitter
Follow InsideRIA on Twitter
Facebook Application Development
I spent a lot of time researching frameworks, but in the end I've found I'm happier with my own custom framework. It's kind of loosely based on Cairngorm. Before committing to a particular framework, I would encourage developers to go through the exercise of setting up their own. It helps engender a deeper understanding of design patterns. In the end, you might decide to go back to a 3rd party framework, but at least you're making a more informed decision. It's good to know what's going on "under the hood."
adampasz, writing your own general purpose framework can indeed be a great exercise. And using your own general purpose framework, as opposed to an application specific framework, can provide many of the same benefits as using one of the more "standard" 3rd party frameworks. I'd say the only drawback is that no one else will know your framework, so it can be a hindrance to collaboration and a negative from a client's perspective because it will be harder for them to maintain your code.
Adam: Good point - you'll learn a lot when you write your own framework.
However, if you have experience with a well-known framework (from what I understand, Cairngorm has the biggest slice of the pie - in the UK, at least), then you are way more employable than if you have only experience with your own framework.
And even if there is a more recent framework (Swiz, Mate, etc), that is in many ways better than Cairngorm, you are still best off (most employable) choosing the framework that has the greatest market penetration.
My thoughts on how we can better find frameworks...
I've never understood the value offered by any of these add-on frameworks - what exactly do they help me do more efficiently than I can already do with Flex itself?
These frameworks generally give you an MVC pattern. They're all written in AS/MXML, so its nothing you couldn't do on your own. But, like I said in the article, there are lots of reasons to use an existing framework rather than creating your own.
apart from orginizing your project code into a managble team effort, a framework is a coding standard and sure one lone ranger can solve all the worlds problems but if you don't put that back into the community you will probably only be solving your own problems for a very long time...
the thing i don't like about the current state of flash developers is that they all seem really happy to do their own thing and brag about their own frameworks but often forget that what they are doing is almost identical to an existing OPEN SOURCE framework and instead of acting so selfish they could have shared or posted some ideas and worked with the team behind that framework to make it better for everybody...
its time to share these amazing ideas or are you just copying and calling it your own? show us your cards so that we all learn...
you guys are so talented in speak of this kind of crazy thing... I don't understand about codex.. coding.. etc.. damn! life I have..
If you like PureMVC, but dislike all the boil plate code, check out HydraMVC - http://www.hydramvc.com
Again, though - isn't Flex inherently MVC? Lists, tables, trees, etc. are all data-driven view components backed by model data. So, I fail to see what these frameworks might add on top of that.
To me, it's not a question of who builds it (me or someone else) - the question is: why do I need this? As far as I can tell, I get everything I need to cleanly structure my application right out of the box with Flex.
Following up on my initial post:
One of the reasons I chose to adhere closely to an existing framework (Cairngorm) when coming up with my own is that it also gave me the opportunity to familiarize myself with code other people actually used. Along the way, I had to make conscious decisions to break away from their conventions. For example, my framework is AS3, not Flex-only. Also, I feel having a separate Class for every type of event it overkill, so I just use a single Event class fro all my events. The experience served me well when I had to work on an actual Cairngorm project -- I was one step ahead.
The "hindrance to collaboration" issue, I feel is minor, but of course depends on your situation. If you already work at a company where everyone uses Mate, then by all means you should learn that. On the other hand, the odds that your going to pick the "right" framework out of a hat are low. Cairngorm was all the rage 2 years ago, but now it looks like it's abandoned (it hasn't been updated since '07). Unless you know you're going to use a particular one on a project, there's not much point in trying to guess the right framework to learn. You should go with the one that looks interesting to you.
I have tried to teach other people my framework. I've also tried to train people on Cairngorm and Pure MVC. Explaining my own framework is actually *easier* because I am so intimately familiar with it.
Again, not something for everyone. For new Flash developers, I would think learning libraries like Papervision, Tweenlite and Degrafa would be a better use of time. Just wanted to share my experience. :)
Greg Brown: I disagree that Flex inherently implements an MVC pattern. I think that it lends itself to that pattern well, but it doesn't give you all the pieces. Where do you store your data for your data-driven view components? You could store them in the same class as the view. That's bad architecture, but Flex has no problem with it. How do you implement your services layer? Again, you could do it all in your view classes, but that's a bad idea.
What most people who don't use frameworks likely do is basically create their own mini-framework -- you create a "model" class to store your data and an event chain for your services. In essence that's all the various frameworks do, they just do it in a way that is scalable. And they move the logistics of the framework into a library out of your code, which you could also do.
Originally there were no frameworks in Flex, people just used Flex and it worked. But people who wanted to follow good design patterns found themselves re-implementing the same basic MVC code in every project, so they wanted to pull it out and make it a library. Once someone has already done that work, why re-invent the wheel? So now most people pick up someone else's framework rather than using one they made in-house. This has the benefit of being "standard" so more people already know the framework meaning more people can start working with your code faster.
Check this out: http://www.comparatio.com . This is a Flex framework based on templates for business apps.
Frameworks can not only help implementing code faster but also make some of the implementation tasks much easier since crucial items are already done (e.g. server back-end, filter and sorting data in the front-end, templates for forms, etc.) which leaves more time for the actual project.
@Greg Owen: Before you disagree on the point that Flex Framework is MVC savvy at its roots... consider a DataGrid as a view, an ArrayCollection as the model, and the controller being implicit in the component (data binding serves as the glue between them). The more time I spend in the Flex SDK source the more I see microcosm MVC at work; agreement on data-flow, proximity (coupling) and at what level these should or shouldn't be happening is another story.
I would like to respond to your comment on "bad architecture" though. Statements like this tend to set the tone that there is only one way to do something and that regardless of how it performs it's that-way or the high-way. I believe that good architecture can and probably should be relative to an implementation... if your app uses plug-ins extensively - tying (from your plug-in) into your base-level MVC construct (in the main app) may make absolutely no sense, may be technically impractical, or perhaps near impossible. If your plug-in is 100 lines long... does it make sense to break it down into a model, view, and controller? Sometimes encapsulation and non-compartmentalization make a whole lot of sense and shouldn't be overlooked.
What I'm trying to say is that good architecture is a balanced product of materials, tools, context, a plan, and ingenuity within a given context. My hang-up is that I feel it's always important in these kinds of discussions to acknowledge that adding a framework to your application toolbox is no substitute for conscientious development. I do agree that standardization is a good thing as it helps level the playing field within a development team but on the same hand I've seen more than a few sloppy Cairngorm implementations. So, saying that a framework forces you to adhere to best practices is difficult to swallow.
I do agree with you whole-heartedly on the need to embrace and become familiar with mainstream frameworks. The more you are willing to learn the better off (more employable) you will be.
Greg Owen:
As Rick Winscot noted, Flex does sort of apply a "model-view" architecture, where the view and controller are combined into a single entity. However, the model and view are definitely separate. The model is something that implements a collection interface (such as IList or ICollectionView), and the view is the data-driven component that is capable of presenting the data in that model (e.g. List, DataGrid, Tree, etc.).
See this section of the Flex docs for more information.
Last comment was from me - forgot to enter my name in the form. :-)