The Model-View-Controller Explanation
This should be a fun one. I wrote an article recently for the magazine about Ruby on Rails, which was meant as a primer to those that aren’t really immersed in programming. Some developer was bound to chime in, and they did, and in fact it went exactly like this:
Which was followed up (after some prompting) by this further explanation:
Both of these are completely accurate (thanks, Lee) and from what I can tell are something that it wouldn’t hurt to explore more in a blog post. If nothing else, it’s worth a stab at trying to relate this to everyone, since it is an important topic.
Let’s start with the Model-View-Controller (MVC) architecture, which refers to a method of programming that Ruby on Rails is built upon. Let’s start an example so that we can relate this to real life. In our example, we want to build a really simple application that pulls articles from a database and displays them as a list on a web page. In order to do this, we will need somewhere to store our article data. In our example, we will use a database to hold our article data, which means that we need to access that database occasionally to retrieve and update information.
Enter the Model. Models are gateways to information, so to speak. We would create a Model class that handles our article data. In this model goes all of the programming associated with managing article data, such as validating information. For example, we will require that all articles have a title, an author, and some content. The programming to make sure that this is provided resides in the Model. In addition, Model classes handle database interactions such as retrieving and updating information. Programmers save time by not having to create all the code to interact with a database every time they want to get information. They simply create a new Model class and worry about more important things.
In addition to storing our articles in the database, we have also set out to display these articles on a web page. You’re probably ahead of me already, but here is where the View comes into play. In the simplest explanation, a View defines the output of particular information. Using our example, we want to display our articles in a list on a web page, so the View file would contain all the HTML code to display these articles the way that we want. The View would also contain some Ruby code to loop through our recordset of articles and display them. Seems easy enough, and Views make creating and managing complex web sites much more efficient. However, don’t be fooled into thinking that Views are only for web pages. As I said, a View defines a way of outputting information, so we could output a text file, an XML file, an RSS feed, JavaScript and anything else we want.
So far, so good. Our articles will be stored in a database, accessible via our Model class. We also have a View class set up to display those articles on a web page, but we are still missing something. Something big. How does the application know when the user wants this information, where to get it, and how to display it? Now we have our Controller class, which will pull everything together. First, let’s outline what our Controller will need to do in order to show our web page of articles.
A user will make a request, in this case by typing in a particular URL into a web browser. Our Controller needs to catch that request, and then determine what to do with it. This seems kind of silly, but take a look at our list of articles. In our Controller, we have defined that if someone types in the URL “/list_articles” on our website it is time to spring into action. First, the Controller will ask the Model to give it a list of the articles to display and place them into a variable that the View file will be able to access. If there is any other logic that needs to be done, such as pulling dates, formatting strings, or anything else, the Controller would take care of that as well. Once the data is received from the Model, the Controller then invokes the correct View that we want to use to display the article data. Passing the information from the Model (as well as any other processing) to the View, the Controller then outputs the view to the user. It seems like a lot, but it all happens in a fraction of a second.
Hopefully that is at least a terribly simplified explanation of what is going on. MVC architecture is not specific to Rails either, it is a concept that is embraced by all kinds of developers (Java, C+, etc) and has proven to be a great way to efficiently develop applications.
As for the “Full Stack” part of the Rails explanation, I can take a stab at that too… I would interpret it to be a description of the way that Rails utilizes one progamming language (Ruby) from top to bottom. To start, that means that the MVC application that we are talking about uses Ruby. However, Rails also includes everything you need for unit, functional, and performance testing built with Ruby. Also, there is a console built utilizing Ruby to interact with your Rails applications via a command line. Top it off with a Ruby-native web server (Mongrel) that Rails utilizes, and I would guess that is what someone out there means by “full stack framework”. But then again, what do I know. As long is works, I could care less how they describe it.
