Josh Sharp design and development. Web pages with purpose.

There's a reason why PHP is growing rapidly as a server-side scripting language — it's very easy to pick up. Many functions are included without needing any sort of namespace importing, and you don't even have to write OO code if you don't want to. Variables are weakly typed and the syntax is fairly familiar.

But PHP's ease of use is also its downfall. Because there are less restrictions on the structure of the code you write, it's much easier to write bad code. But there is a solution: use a framework.

PHP frameworks like CakePHP, CodeIgniter and the Zend Framework (which I wasn't too taken with) provide a solid structure for your code whilst also offering some extra functionality that would be much harder to replicate on its own. It's important to note, too, the frameworks mentioned follow the MVC pattern, which is fairly common and what I'll talk about below — some of these benefits will apply to other patterns as well, but not all.

Of course, if you're not taken with any of the packages above you can also write your own framework, which I've done and will talk about in the next few posts. But for now, let's have a look at the common benefits of a framework.

MVC structured code

Model-View-Container is a widely recognised design pattern that separates out database and business logic from the presentation layer (in this case, the (X)HTML). Separation of presentation and logic aids in maintainability — clean code is easy, understandable code. It means you're no longer searching for that elusive function returning you an empty array — so it comes from the database? It must be in the model. On the flip side, it also means you can update the look and feel of a site without having to worry about wading through PHP script tags. It's like the server-side equivalent of CSS.

Enforcing of good coding standards

Another effect of MVC code is that it makes it so much easier to code as you should. For example, in my framework Rex, the Model is covered by two abstract classes — DataObjects and DataHandlers. DataHandlers instantiate and manipulate DataObjects, which are basically big associative arrays wrapped lovingly in getters and setters. But here's the neat bit — DataHandlers are the only object which can access the database directly. Of course, you could get around this if you wanted to, but by sticking to rules like these, you save yourself months of headache. If your User records are failing to insert, well no contest — it's an issue with UserHandler. Too easy.

Pretty URLS

Most of these frameworks use a bit of mod_rewrite magic to ensure your URLS are always clean and accessible. Apache handles requests to a particular URL, and (hidden to the client) returns this URL to /index.php as a GET string. The index page instantiates your main framework object (in Rex's case, the App object) and farms the query off, and you're done. But all the end-user knows is that they're at /users/browse/page/2 — they don't ever even know you're using PHP, for that matter!

Accessible URLS also help with SEO — linking to your blog post as /blog/view/why_you_should_be_using_a_framework/ is going to boost your search engine ranking for those keywords more than /blog/view.php?id=12 ever could.

Helpful helpers

Remember how every page query starts from index.php? I promise this will make your life so much easier. Everything you need can be included into a few main files — no more forgetting to include formfunctions.php into that statistics report page. You would not believe how good it feels the first time you realise you never have to include anything manually again.

Of course, with all that spare time you now have, you can get to work learning how to use the helpers that are now helpfully included into every page. No more manual validation of forms — just instantiate a new form validator object and tell it what you need. No more passing error messages in GET strings (and I've seen some terrible examples of this) — your form helper can flag errors on your fields when it reloads the page. Welcome to the land of milk and honey, where there are helper objects for all the fiddly things you once did by hand.

Less time coding — you're so efficient you just put yourself out of a job.

It doesn't take a genius to figure out that using a framework saves you stacks of time and effort. It really does enable you to do things you would only have dreamt of, back when every page had its own controller (or however you choose to do it — that's the sin I was guilty of).

As I mentioned, if you stick around I'll take you through how I wrote my own framework so you can write your own too. It's perfect for anyone too anal to bow down to someone else's way of naming objects :)

Have I missed anything? Are there disadvantages to frameworks you want to mention? Let me know in the comments.

Update: some further thoughts on the topic here.