Custom PHP MVC Tutorial: Part 1, introduction

Posted on 14-10-2011

If you code your web sites/apps in ASP.NET or Ruby and you're in the market for a MVC framework, you don't have to look very far - ASP.NET MVC comes with the latest Visual Studio, and Ruby's resurgence in the land of web dev can largely be attributed to the trendy Ruby on Rails MVC framework. What about good ol' PHP, though? True to its open nature, PHP has a bunch of popular MVC frameworks to choose from, each with their own assortment of positives and negatives to consider. However, before you go off on an epic Googling quest to pick one, have you considered writing your own?

This multi-part article covers just that - a step by step look at making a very no frills, basic MVC framework for PHP. Obviously if you come out the back end of these articles with a code base identical to what I propose you wouldn't have technically made a custom one yourself, so the aim of this series of articles is to demonstrate how it might be done, and perhaps give a gentle nudge down the path of creating a personal framework you can mould to your requirements, and use time and time again for future projects with complete confidence in how everything pieces together.

Before jumping into the nuts and bolts of how our MVC framework will look, let's briefly cover why you might want to take this custom path. After all, there are some very high quality PHP MVC frameworks out there that genuinely improve the PHP developing experience, but do you know the ins and outs of these frameworks? Are there unnecessary layers for your particular project that may be impacting on performance? Or security? Or just overall efficiency? Are you comfortable building your projects around code often openly available, that you may not fully understand? In a lot of cases, or even most cases, these concerns are going to be pretty minor, but if you enjoy coding in PHP and have some time up your sleeve, then why not spend some time making your own?

Now, if you've made it this far into this article and don't actually know what all this "MVC" talk means, then you probably need to open another browser tab and read up, as in-depth theory behind the MVC design pattern is out of scope in this article. What I will do though is give a very brief overview - M stands for "Model", V for "View", and C for "Controller". What this means in very simplistic terms is a way for developers to build web sites/apps with clear separation of code - putting business logic and data access in one place (the Model), presentation code (e.g. HTML) in another place (the View), and an authority behind the scenes which combines the two (the Controller). MVC also goes hand in hand with Object Orientated programming, which PHP emulates. For some projects, MVC and OO is overkill - a pamphlet site with a single contact form could be done much simpler, for instance. However, for any project involving database access, user sessions, and all that other cool complex stuff we love to make, MVC is a beautiful system.

Again, if all of these terms are new to you, you may want to read up more on the subject before proceeding, because it's time to get technical and start describing the custom MVC framework we want to make. To do this, I will make a list of criteria for this custom framework to meet, and each article in this series will cover how you may go about doing that in more detail.

The URL structure should follow the standard MVC pattern of http://domain/controller/action/id, where action and id is optional.
Index.php will be our main "landing page", and is the single point of entry for all requests.
Index.php will establish a "loader" object which is responsible for translating the requested URL into an instance of the relevant controller class, and then executing the requested "action" (i.e. method) on that controller instance.
Our controller instance will have a basic level of validation and error handling regarding any bad requests in the URL.
Controller actions/methods are responsible for creating an instance of the relevant model and sending the model's return data to the appropriate view.
Views can be either stand-alone or use a template (in practical terms, this means views could return AJAX friendly content or normal browser based page requests).
All controllers, models and views are individual files organized in relevant folders of the same name. The views folder has a subfolder for each controller. Controllers and models files are individual PHP classes, while views files are PHP capable, but mostly containing markup (XML, XHTML etc).
Controller actions/methods are paired with their view files by name (e.g. the URL /article/update has its view stored in /views/article/update.php).
Controllers and Models each have a "base class" which they inherit/extend.

And here is a simplified diagram to summarize how the framework flows:

MVC Diagram