Question

Other than standard OO concepts, what are some other strategies that allow for producing good, clean PHP code when a framework is not being used?

Answer 1

Remember: MVC, OOP and tiers are design concepts, not language constructs, nor file-structuring.

For me, this means that when not using a framework, and when there’s not different teams for programming and designing; there’s no value in using another template system on top of PHP (which is a template language). Also, separating code from layout doesn’t necessarily mean doing it on different files.

This is how i used to do for one-off, seldom expanded, PHP web apps:

1. write a ‘general utilities’ file, there i put some formatting/sanitising functions, as well as a few DB access functions:
   1. getquery(): given a SQL, returns a result object
      • getrecord(): given a SQL, returns a record object (and closes the query)
      • getdatum(): given a SQL, returns a single field (and closes the query)
      • put all configurations (DB access, some URL prefixes, etc) on a ‘config.php’ file
      • write a model layer, either one file, or one for each object you store on DB. There, will be all the SQL constants, present a higher-level API, based on your conceptual objects, not on DB records.

that’s your ‘framework’, then you write the ‘presentation’ layer:

4. one PHP file for each page, starts with some simple code to fetch the objects needed, followed by HTML with interspeced PHP code, just to ‘fill in the holes’. with very few exceptions, the most complex code there should be for loops. I make a rule to use only one-liners, the ?> should be in the same line as the opening <?php

   • each data-entry form should point to a small PHP without any HTML, that simply get’s the POST data, enters into the DB, and forwards to the calling page.

and that’s it. If working alone, it has all the separation of intents you need, without drowning in a lot of files for a single user action. Each page as seen by the user is managed by a single PHP file.

It’s even easy to maintain, after a few months without looking at the code, since it’s easy to test the app, taking note of the filenames in the URL field of the browser. This guides you directly to the relevant code.

(nowadays, of course, i’m using Django for almost everything…)