Home

Easy as MVC: Architecture and Frameworks for Non-Believers

I've been to several "pattern"-sessions at former conferences, but none of these have tried to claim that pattern based programming is easy.

Session presented by Robin Hilliard
Robin is well known in Australia and the Asia region. He is the manager of the national australian User Group and one of the people behind Rocketboots a big australian consulting agency specializing on Adobe software.

Think about the investment the client does by having you cranking out code. If one is professional, one should protect the clients investment. How do you protect the customers investment? By carefully planning how you lay out your application. If you know the client will change certain parts of the project, you'll want to isolate this so it does not affect your work too much. By minimizing the number of dependencies in the project planning phase, you'll be way better off towards the end of the project.

For many applications, the data is the thing that will probably stay most consistent. The next thing that is more likely to change is Business Logic. Even more likely for change is the Application workflow and finally the thing that is almost certain to change is the Interface (UI, webservices and all other points where our applications touches the world).

The solution is Model View Controller (MVC) - a way to organize your project/code using a "pattern" as a guide. A pattern is just a solution to a common problem and in the case of the MVC pattern, it's one that avoids bad dependencies in applications with user interfaces.

The various components of the MVC pattern are:
Model - Knows about nothing. This is the part of your application that holds the current state of the interface such as data for address lists, the currently selected record and other data.
View - Knows about both the Model and the Controller. Handles what the user sees. This is the bit that is most likely to change.
Controller - Knows about the Model. This is the application workflow that handles and dispatches all the required Events.
Business Logic - Used by the Controller. Handles server calls, filters, validators

By structuring your classes according to this model, you'll avoid too many dependencies. The controller and business logic will take care of updating the view so that the model that handles the data does not need to know about the view. At this part, Robin all of a sudden started making assumptions that the audience knew what a Singleton- or Worker-pattern was and I almost slipped. Just minutes later I totally slipped as since he was pressed for time, he all of a sudden started talking about Cairngorm and pattern based frameworks and rushed into a demo. Too bad that this presentation had to end this way, for this was one of the best sessions I've attended on MVC. Very well laid out and explained.

Just for populating a datagrid, this would seem too much, but for a larger application it is crucial. Robin's example application consisted of more that 120 different classes and a lot of serverside and client technologies. For such a big application, flexibility is crucial and using a MVC framework like Cairngorm as a starting point, this big project was actually manageable. One good final point was: make sure you understand the basic MVC idea before using a framework such as Cairngorm.

Written by Jens C Brynildsen (March 22nd 2007)