Building a MVC Framework - An Introduction
Table of Contents:
MVC stands for "Model-View-Controller", and is the first design pattern we'll take a look at. In short, it's the idea that we code in a way to separate our domain logic from our presentation logic. Fancy, but what does that mean? Let's take a quick look at a common problem we might face:
function showTable() {
$query = 'SELECT * FROM users';
$result = mysql_query($query);
$output = '<table>';
while ($get = mysql_fetch_object($result) ) {
$output .= '<tr>
<td>'.$get->name.'</td>
<td>'.$get->address.'</td>
<td>'.$get->age.'</td>
</tr>';
}
$output .= '</table>';
print $output;
}
Hopefully we can see a number of glaring issues with that so far. What if our application cannot use mysql? Imagine the fun involved in changing all references from mysql to some other database. What if our designer decides tables are so 1998, and wants a full CSS styled <div> based layout? Surely we wouldn't want them poking around in our code.
Imagine then, if we had a central controller to handle how data is passed around. Perhaps it could look something similar to this:
$user = new User();
$data = $user->getData();
$view = new HTMLView();
$view->load($data);
Already this is starting to look cleaner. We've been able to push the user data collection off into it's own object, and then transfer that information to our selected view. We can see quickly how we have separated the logistics behind how we got our user information, and the logistics of how that information will then be displayed.
MVC is the cornerstone of the framework we'll be building, so it's important to understand the separation taking place.
Testing it all!
As we go through the process, we'll also be writing unit tests for our framework. It can be difficult to objectively quantify the benefits of testing, but after getting used to it, there's a good chance you'll find yourself writing tests for the simplest of scripts.

