Cartoon Clouds
Mountains
Sunrise
Clouds
Green Clouds
None
An introduction to MVC architecture
The cleanest way to write all webapps
A Guide by Kyek
Written March 10, 2010
Most... Valuable... Cake?
MVC stands for Model, View, Controller. For years, it's been the standard for how to split the code of a web application, and for good reason -- once you try it, you'll see that there's just no better way to organize the pieces of your project. It makes your work faster, more maintainable, and much easier to reuse in other places.
Understanding the pieces
The easiest way to understand MVC is to imagine someone typing your website's URL into their browser, and that page request hitting your web application. From there, here's how the pieces of the MVC puzzle come together:
Controller: The "Controller" takes the request and reads it, figuring out what the user wants to see. Looking at the URL and the data that was passed along, it appears that the user is trying to look at page two of your blog. Great, the controller's main job is now done! It's identified what needs to be delivered. Now it has two other tasks to do: It has to create the Model, and pass it to the correct View. What are they, you ask? Read on!
Model: The Model is a fancy name for the object containing all the necessary data for the page. In our example, the user has requested page two of your blog. So the controller tells the model "Load Blog page 2 from the database!". The Model's job is to do ANY data-related related task, from database communication to file access. Then it stores that data inside of itself -- all the data needed to construct the page.
View: Now that the controller has identified what's being asked for AND it has the model ready to go, it selects a View. The 'views' are the different display templates for your site. You could have a view for your site's landing page, a view for a blog post's comment section, and a view for pages of blog posts. The view has, at minimum, all the HTML that's needed to display a page, and just enough code inside of it to use the data that's being provided in the model. So in our example, the Controller will send the Model that it has ready to the Pages_Of_Blog_Posts view. The view looks like a normal HTML page, but there's a little bit of code to dig into the model and show that it's page "2" we're looking at. There's a little bit of code to loop through each blog post that's been returned, dumping in the name and a snippet of its text. There's a little bit of code to see that we're on page 2 and that there's a total of 5 pages, so it knows to put in both the "Previous Page" and "Next Page" links.
Wow Kyek, that almost seems too simple!
Well, it's a little more complex than that. Let's take the controller, for example. Modern web applications have a set of controllers -- one to handle each kind of request. Requests for blog pages get sent to the Blog Page controller. Requests for the Blog Comments get sent to the Blog Comments controller. Requests to search the blog goes to the Blog Search controller, and so on. So how do the requests GET to each of those controllers? Well, you need some sort of dispatcher that reads the request and knows which controller it should go to. That, itself, is also part of the "Controller" side of your web application.
The Model is a BIG one that has a few different interpretations. Originally, the word "model" referred to only the data that gets passed to the View, and in some contexts, that's still what people mean when they say "model". But for modern web applications, the Model part of the MVC structure isn't just the data, it's also allll the logic involved in retreiving, saving, writing, or manipulating that data. "Fat Model, Skinny Controller" is a common phrase used to describe where the heavy lifting should happen in your webapp. Controllers should only figure out what type of model needs to be called on -- the model should do every last bit of the data work. So if you're using a database wrapper to support more than one type of database, for example, that's still considered part of your Model.
The View seems like the simplest part, right? Just HTML with some code thrown in to dump out the model's data. But it's often anything but simple. Think about a full, polished website. It probably has a header that appears on every page, right? And maybe a sidebar that's on more than one page, and other parts that are shared between different pages. The first rule of programming is to never have duplicate code, so for the view, you generally want things like your header and your sidebar and your footer all in their own separate files, which can be dynamically included into your main content pages. So the view for our example (loading page two of your blog) may look something like this (just an example here, not a real language):
INCLUDE PAGE_HEADER INCLUDE LEFT_SIDEBAR << Code to display blog posts here >> INCLUDE GOOGLE_ANALYTICS INCLUDE FOOTER
And sometimes the people making these views aren't coders, so instead of letting them work with very sensitive PHP or Java or Python, you'll want a mini scripting language for them to use that you'll parse with the controller so that you can be sure these people can't break your site.
Sound like it's too much? It's not, if you start easy!
If you've never built an MVC-structured webapp before, don't be scared off by the complications! You can build very simple and tiny apps with MVC architecture without getting into all that complicated-ness yet. Make a simple controller that can tell what's being requested, make a simple model that only supports one way of storing data, and make views that are simple HTML files that might reuse code here and there. The beauty of starting with that MVC structure in mind is that, at any time, you can make any of those parts more complex and more featureful without ever needing to touch any of the other parts!
So after your app is built, then spend the time to make your Model faster at getting and storing data, and your controllers and views won't care. Then maybe you'll decide to support multiple themes in your view, and your models and controllers won't care about that. You can do upgrades however, wherever, and whenever you like without risking breaking anything. So start easy, then work on making things more advanced!
When should I try this?
If you have a basic understanding of any server-side web language, there's no reason to wait! With how very simply you can do this, it's a great way to start learning. So from here on out, don't build any more webapps without thinking about how to split it up into those three pieces
Go forth and code better!
.
Help
Register Now!