Rolling Your Own MVC: Introduction
2007 was the year of framework development for PHP. Cake, Code Igniter, Zend, Solar, Symfony, and piles more began to really get some well deserved attention. Today, you can throw a rock and hit a half dozen production-ready frameworks that are actually worth using.
Last year, I spent quite a bit of time surveying each framework and seeing how they decided to put things together. Maybe you did too. If so, you probably thought the same things I thought when I saw the core code for the first time: “Eww! Why did they do it that way?” or “Man, I could have done a much better job than that…”
Well yeah… You can. And I’m going to show you how.
Over the next couple of posts, I’ll be walking you through the process of developing a simple MVC framework that you can use as a starting point for almost any PHP application that needs to be developed. Furthermore this framework won’t be like any other framework you’ve seen: it’s going to be small enough to not obstruct the real development, elegant enough to make it a pleasure to work on in the future, and scalable enough to be useful in the development of applications of any size. How? By keeping things simple and resisting the urge to add tons of stupid features.
Remember, it’s just a framework. Save the real coding for the application.
The Ground Rules
Before we dive into the deep end, let’s get a few things straight. Everyone has their own way of interpreting the concepts I will be presenting so before anyone draws any premature conclusions, I’m going to lay it all out in the open.
In no particular order:
- MVC is a design pattern — not a framework. Most of this framework’s code base will be written toward MVC components, however that still does not make it a stand-alone framework.
- Frameworks should have a small set of responsibilities. The framework demonstrated will only be responsible for the page load scenario.
- This is all part of a side-project I am in the process of bringing back to life. If you want something that offers a bit more, be sure to follow up on the project every now and again.
- It is my most sincere hopes that by documenting my experiences here, you too will be inspired to develop your own framework. If you want, please feel free to use my code as a starting point — but be aware that I am releasing it under the New BSD License. This means that it’s damn near public domain, but you have to send some credit my way if you want to use the code.
- Only PHP 5 will be used. There’s absolutely no point in wasting time to support people who refuse to stay current.
- The API will be delivered using a set of abstract classes and interfaces. When it comes time to write an application, simply extend the class you need.
- This will be an evolving project. Although I’m quite settled on how this is going to work, I predict that the feature set will change.
The Feature Set
Even though the goal of this framework is to be lightweight, it still will need to have a reasonable set of features to make it worth using. The following list are things that I think are requirements in any modern PHP framework:
- Controllers that prefer REST-based requests, but can be force-fed an action in case the client doesn’t fully support the HTTP spec (web browsers for example) or if that’s just how you prefer to structure your URIs.
- The ability to emit any data type: HTML, XML, JSON, Serialize PHP, or anything else you wish to define.
- The option for anything to be overridden with new functionality.
- Models that represent any kind of data — not just database records — as well as provide a uniform API no matter what the data type is.
- A template system that supports master templates and partial templates. No custom template language. No separate header/footer includes.
- Automatic dependency location by user-defined parameters.
So why reinvent the wheel?
Because you can. Because you will learn a great deal. Because all other frameworks are great for getting an application off the ground, but come with a lot of extra baggage that you simply don’t need.
The reality is simple: frameworks aren’t that big of a deal. Just because is big, bulky, and bad ass doesn’t mean that you can’t make something just as good… even better since it will be your framework.
We’ll talk soon.
Other Posts in this Series
- You are reading Part I: Introduction
- Part II: The Page Load Scenario
- Part III: The View
3 Responses to Rolling Your Own MVC: Introduction
mikeg:
Ryan, Thanks for the feedback.
I couldn’t agree with you more. Everything you listed above is critical to the successful deployment of any web project.
When it comes to metrics and unit tests, they certainly play a vital role but I’m not convinced they belong in the core of the system. On the other hand, proper error reporting and security should always be part of any system.
The goal here is to write a handful of small classes that don’t make any assumptions. Each class will do one thing, and do it well. This will leave the option open for one developer to use SimpleTest and another to use PHPUnit and another to not write any tests at all.
You can certainly count on me including my tests with the code — but just not part of the framework.
Rolling Your Own MVC: The View :: Love Mike G.:
[…] to the third part of my series on MVC framework development. In the previous two articles, I discussed the general feature set that our framework will have and I also gave an overview of the page load scenario. In […]
Ryan Price:
On February 22nd, 2008 at 4:33 pm #
Mike, I agree with all of your points here, but I would caution all but the experienced programmers to tread this path.
In his first year of writing code, any young buck appears to be obsessed with writing it all himself. These are not the folks I recommend taking your path, unless they are utterly committed to achieving all of the goals you’ve set here.
Also, what about metrics? Testing? Error reporting? Security? Not part of the framework? Not part of this blog post?