My posts on team development will start from a beginners understanding of programming, working up to an advanced look at architecture and design.
First thing’s first: What’s this MVC thing?
MVC stands for Model-view-controller. MVC aims to separate, or decouple, data (model) from the user interface (view) and functional logic (controller). You can read a lot more about MVC on the Wikipedia.
How do we use MVC in an RIA (specifically a Flex app)?
Well thought out architecture and design is important at every level of the application, but an RIA is different than a web app of the past in one important way: state. In legacy (HTML script-based) web apps state is, for the most part, required to live on the server. In RIA development we are not bound by this requirement. We can build RIAs that have state at the client or the server or a hybrid of both. This one fact completely changes the complexity and importance of what once was merely the view. In RIA development the part of our application that lives at the client level is not just an HTML rendering of a view, it can be a fully functional stand alone application. The client in a RIA has many of the characteristics of a desktop application and that is why MVC applies at this level.
Why is this called a micro-architecture?
We refer to architecture and design patterns at the Flex level as a mirco-architecture frameworks because the Flex application is a piece in the larger picture of the entire application. The Flex app may talk to one or more web services, consume an RSS feed, stream video, show images from the web, and so on. All of these services fit into the larger architecture of the web app. These architectural decisions are also important but a little harder to talk about generically. So, since this is a Flex blog, when I speak of architecture I’ll really be talking about client micro-architecture.
Why do you want to use a micro-architecture?
Actually, sometimes you don’t. If you’re creating a very simple app (something like a widget or a banner ad) MVC might not be for you. However, if you’re creating something that models data retrieved from a service, allowing the user to manipulate that data, and displaying the data in interesting ways… MVC is really a good choice to make.
What you get
- A code base that facilitates team development.
- A skill that will make your team more agile in their development life cycles.
- Source that has a high level of maintainability and interoperability.
Ok.. let me unpack those a bit.
1. Your code base will facilitate team development most simply because the team is now coding to a convention. MVC isn’t really the big deal here, it’s the fact that a convention was decided on. MVC does offer some nice things in regards to team development that I’ll talk about in other posts, but my point here is that convention keeps everyone on the same page.
2. Every learn how to play an instrument or a sport? Each of these skills involves mastering patterns. The more your team implements on the patterns in MVC, the better skilled they will be at it. My point here is really that MVC should also be viewed as a problem solving tool. When you get developers thinking about solving architectural problems in the same way, everyone can solve that problem faster.
3. Maintainability and interoperability… again this really goes back to convention. Your code will be more maintainable by your dev team if it’s built on convention. If you chose a convention that’s fairly mainstream, then you gain a level of developer interoperability. Meaning, training in a new team members on the way you implement requirements will be a lot easier if your using a convention and on top of that a standard convention. In Flex development, Cairngorm is a nice way to go. It’s not necessarily the best framework out there, but it seems to be the most widely adopted Flex micro-architecture.
I’ll be delving deeper into MVC and Cairngorm in my next posts.