Include-Based vs Class-Based Architecture

This is a topic I describe at length in my Organizing talk, but I would like to give the idea a home on my blog for easy reference.


Typical PHP uses what I call an include-based architecture. By this, I mean that the mere fact of including or requiring a file causes the execution of program code or business logic.

include 'config.php';
include 'header.php';

// ...
// do some work, probably including other files
// ...

include 'footer.php';

The application is composed of files that the user browses to directly. Those included files may include other files for additional business logic. This is the basic structure of most PHP applications.

At some point, the PHP programmer starts writing his own functions to encasulate repeated behaviors, and starts including a file of those functions. As a follow-on, the programmer may begin to adopt object-oriented programming and start to collect his functions into classes along with related data structures.

The functions and classes do not end up changing the basic structure of the include-based application. The programmer still has a series of pages that users will browse to directly. Those pages load up classes and functions and use them as helpers to perform business logic that is mostly still in the page script.


By contrast, a class-based architecture is what we generally see in the MVC frameworks of the past 10 years or so. The user browses to a bootstrap script (the only “page” in the whole system). That script then reads the request and picks out a business-logic class to instantiate, and calls a method on that object instance to make it run. From that point on, all behaviors are contained in class methods, not in page scripts. This is what I mean by a class-based architecture; that is, all of the main program logic is embedded in classes, not in page scripts.

In talking about the distinction between include-based and class-based architectures, one programmer I know said, “There’s no real difference between include-based and class-based. You still need to include the class file, after all.” Yes, you do need to load the class file. The difference is that no program logic is executed at loading time with a class file. Loading the class file makes it available for use, but the programmer has to instantiate it and then call methods on it for anything else to happen. With include-based architectures, merely loading the file will execute program logic.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.

8 thoughts on “Include-Based vs Class-Based Architecture

  1. When you say “The user browses to a bootstrap script (the only “page” in the whole system)” you are talking about a front controller, which is not the same as MVC. It is possible to have MVC with separate page controllers, as can be found in the Radicore framework at

  2. If it is possible I try to follow the (not yet mainstream 😉 convention that the filename-extension: .phps is used for library code and .php for script code. Library- and script-code could be compared respectively to the above mentioned class- and include code, though it makes a slightly different distinction. Important side-effects are that it is clear which is runnable and which is (if .phps is showing the highlighted version) readable.

    Functions like classes get their own file in a dedicated directory in the include_path (like PEAR’s Php_Compat).

    Also, an autoloader should take spl_autoload_extensions() into consideration which I hope will be configurable in php.ini in the near future.

  3. Includes should have not be able change server state.

    In my bootstrap I usually have something like

    $container = (include ‘wiring.php’);

    Where wiring.php instantiates and configures a dependency injection container.

  4. This is all just another shade of imperative vs. declarative programming, i.e. the literal dictation of program flow from beginning to end, vs. describing a system as a series of components and interactions, using classes (or whatever, really; the OOP conception of classes is just the best general solution we’ve come up with so far).

    I think expressing the concept in those theoretical terms would advance new developers’ understanding of the distinction much better. Also, when you’re get into the practical, there’s too much for these young punks to be smart-assed about. 😉

    @Tony Marston:
    I can tell you first-hand that Jones knows the difference between the Front Controller and Page Controller patterns. In fact, the frameworks that he’s referencing pretty much all use both patterns together: the front controller acting as the gateway script to the rest of the framework/application, and individual page controllers to route requests to (the C in MVC). However, in the context to which you’re referring, “page” literally means a PHP script, not a class or pattern.

  5. Oh common, we have XXI century, just use oop with autoloading and leave “include” thing behing..

  6. @NateAbele
    Personally I agree with Mr.Marston. PageController and FrontController are to MVC what ActiveRecord and DataMapper are to a Domain Model. To be fair, that’s probably a bit too much scope for this article, but it’s worth a mention.

Leave a Reply

Your email address will not be published. Required fields are marked *