Beginners Guide: Model, View, Controller (MVC) Architecture

Posted by Tom Rossi on July 29, 2006Comments (16)
Ruby on Rails, Tutorials

Beginners Guide:

1. Getting Ruby on Rails Running on Windows
2. Introduction to MVC
3. Starting With The Model

Introduction to MVC

At this point, a lot of tutorials and training out there will jump right in to creating a simple application. While it is definitely impressive, I really didn't have a clue what I was doing. I think it is better to first get an introduction to the paradigm or thinking behind a Rails application. Specifically, the archicture of a Rails applicaiton is based on Model, View, Controller or MVC. This architecture has been around since the late 70s and certainly isn't limited to Rails. While I've never used this approach with ASP.NET, I'm now starting to see discussions about how to apply it. Probably the big difference is that Rails will make it difficult for you if you don't think in MVC, while ASP.NET couldn't care less. This is something we will see a lot with Ruby on Rails: the Rails architecture will intentionally make things difficult if you do not follow its conventions. You can either embrace the constraints or spend a lot of time fighting them. This is by design and recognizes that developers will take the path of least resistance.

Okay, so this post will be a lot of theory stuff and I will try to use a lot of the jargon that you will run across as you read other materials. For some of you, you may know all this (and a whole lot more than me!). For that reason, I will include a bottom line to each section.

The Bottom Line: MVC is an approach, paradigm, design pattern, or archictecture (pick your favorite) that defines the heart of a Rails application.

What is the Model?

The Model is my favorite part of the MVC. This is where we define all of the entities which will be acting and acted upon within the domain of our application. For those of you that are not too familiar with object-oriented programming, these entities are referred to as classes or objects. For instance, the application we will be looking at shortly will be a contact management application, I expect their to be contacts, groups, and relationships to capture or encapsulate the people we are tracking, the groups they may be a part of, and their relationships to each other. You could say that for the class Contact you will have one instance called 'Tom Rossi'. 'Tom Rossi' is just one object of the class Contact.

Within the model, we describe the classes by defining their relationships to other classes, their attributes, and the methods performed by or to them. From my previous example, the contact model is related to the groups model in that contacts can be a member of a group. The attributes associated with a contact would be things like address, full name, email address, etc. The methods performed by or on a contact may be to join a group, update contact information, create, or delete. All of this belongs in the model of our application.

The Bottom Line: The model is where we define all of the entities which will be acting and acted upon within the domain of our application.

What is the View?

This is by far my least favorite part of the application. I would imagine everyone would agree! This is where we write code specifically for interfacing with our users (those entities that will be acting on our application). The view is all about interfacing outside of our application. In the example of our contact management application, the view will be where we present our users with their interface to search for contacts, enter new contacts, specify group memberships, etc. Notice however that the real logic that will be executed (the business logic) will be executed by methods contained in our model. For example, we may have a view for users to create a new contact, but the method for creating a contact is within the model for the class Contact. The view is strictly the interface component. The more that we can keep the presentation logic seperate from our business logic the happier we will all be! Any old ASP programmers out there?

The Bottom Line: The view contains all of the presentation logic necessary for our users to interface or initiate actions on our application.

What is the Controller?

The controller interprets the users interactions and interfaces with the view and model. For example, in our contact management application, the user may click on a link to sort contacts by name. The link was presented by the view to the user. Once he clicks on the link, he has initiated an action. This action will then call the model for the contacts with a sort method. The controller contains no business logic and deals strictly with exposing methods contained in the models to the user through the view. I hope that made sense!

The Bottom Line: The controller processes all of the user events or actions and provides the interface between the view and model.

Conclusion

Well, I may win an award for one of the most boring posts. I have to say though that understanding MVC will REALLY help you understand Rails. I will try and get the next post out as soon as possible so we can get back into some real application of this stuff!

Please post a comment if I did not provide a good enough definition of any term I have used or a related term that you have seen in your other reading!