I spent the past few days fighting over the following battle, do I either use an existing PHP Framework or Build One.
I’ve currently been using my Model 1.5 Framework (ScottWork) for sometime, but have been using CodeIgniter on a few client projects and dabbling with some of the leading PHP Frameworks like Zend, Symfony, DooPHP, Yii and CakePHP.
All of this MVC stuff of course got me thinking, what if I want to get other developers to code for me? What if I want to get other developers to maintain my apps/code? What if…?
So I write my own MVC framework here’s a summary if it’s main components:
- mod_rewrite and routing of request – This is basically the nice thing like removing ? and & from your URL so it looks pretty AND automatic routing of URLs to controllers->methods().
- Controllers - This is basically taking your request, and channeling it into some OO paradigm that allows you to “act” on your request in an object oriented way, then route your way to a “view”. It also contains all your logic and calls to your Model.
- Models - This allows you to talk to a database and controls your interaction with that database.
- Views - This presents your data combined/calculated/manipulated/read or otherwise transacted in your Controller.
- Helpers - This is a bunch of pre-built functionality designed to make the framework easier to use and code less.
Here’s my opinion of those main components after comparing them to my Model 1.5 framework (scottwork).
- mod_rewrite and routing of request – I see a lot of uses for mod_rewrite but the routing of request to some kind of controller/object oriented thingy is really a waste of time. Why have one huge controller with a bunch of methods in it, when you can just write a simple script designed to process the input of a page? It’s small, modular which means easy to maintain, there’s no object to create, or routes to manage. The easiest thing about not using some kind of route manager is that you can create a new page that reads data, by just adding the page, no controller/route/setting data to be read by the page later, it’s all right there, one php page. Vertict: mod_rewrite (yes), routing (no).
- Controllers - You don’t need an object to call other pages, most frameworks just use the good-old include() statement, or they wrap it inside some output buffering, but essentially it’s an include. What I do in my framework “scottwork” is to create a processing page (it does not have any HTML) which is essentially the same contents of a controller method, but it’s in one file that’s only job is to process the data from the one page. Vertict: controllers (no)
- Models - I use ADODB and a generated model based on that library. The model is good-old-fashion prepared statements with CRUD operations and basic validation to so that you can insert/update/delete and read-by certain fields. I extends the generated file with a child DAO that allows me to override CRUD operations or do new operations specific to my app. Vertict: models (yes)
- Views - This is completely ridiculous in MVC, the bindings and coupling between Controllers and Views is much worse than just having separate files with single methods. Plus for read-only pages, you just need to create your view, no controller->render_view() non-sense. Vertict: views (no)
- Helpers - This is a bunch of pre-built functionality designed to make the framework easier to use and code less. Vertict: helpers (yes)
You could use a framework or spend time writing your own MVC framework as I have done. Some people like OO, some people like the order/structure a framework provides. Personally I don’t like spending lots of time coding, so I generate most of my stuff. I also don’t like spending time figuring out a framework’s shortcomings or finding bugs in a framework. I believe in writing small testable, programs/scripts (web pages) that do one thing and do them well.
Some interesting reading: