Tuesday, July 27, 2010

MVC WTF?

It has really been that long since I studied programming but as I’ve started looking at some of the iPhone Development Lectures from Stanford on iTunes University I’ve noticed them talking about some things that I’d blocked out (Assignments and exams) and some things that I’m not sure I’ve ever heard of such as the Model View Controller architecture pattern. In the case of MVC I am not sure whether it is because I mostly did low level programming courses at Uni or because it is the latest pattern to re-emerge as favourite among the development community.

In an effort to get more comfortable with the concepts involved in the MVC pattern and how to program within it I thought I would right up a short post. You may have noticed that some of my posts seem more like brain dumps than anything else, this is because I often reach a point of enlightenment or understanding on a subject when I attempt to explain it to someone else. In this case, all my readers get to be that someone else. I am sure there is some amusing quote that I should be quoting to illustrate my point here but a ten second google didn’t reveal it to me

The basic premise with the MVC pattern is that you have a Model which represents and contains the data that the application uses, a View (or collection of views) that is a rendering of the data, or subset of data, in a way that allows user interaction and a Controller is  the glue that links everything together.

Models store data and provide domain logic that provides some meaning to the raw data, such as ranking information or totalling a shopping cart, when a model’s data changes it will notify its associated view via the controller.

The Views are what the user sees and interacts with, they are the visible side of the program and are related to a specific model or model subset, they know how to display the data that is contained in a particular model in a way that is meaningful to the user. A view allows a user to modify data in the model by sending events to the controller, which decides how to handle them.

The Controller oversees the interaction between the View and the model, the controller contains the application logic and determines how a View modifies data within the model.

As I said, this post was to clarify things in my head, I hope you found it useful, but be warned there will be more posts like this coming your way.

1 comment: