I first started building PHP web applications in 1997 when PHP was in version 3. Templating systems didn't exist then; object-oriented design was not a viable option; and the PHP code was downright ugly. Today, I work with PHP 5, which has a vastly improved object-oriented programming environment, mature templating systems, hundreds of useful PEAR packages, and powerful open source databases. With these advances, it's no longer acceptable to write PHP code that looks like linguini that's been thrown against the wall.
PHP now enables you to build robust, manageable, and beautiful enterprise web applications. The best way to do that is to divide the application into three components: model, view, and controller. In other words, you need to separate the presentation, the database, and the business logic from each other. The most common approach for achieving this design goal is to adhere to a strict Model-View-Controller (MVC) framework (see Sidebar 1. A Brief History of MVC
The greatest advantage to separating the application into discreet components is that you end up with software that doesn't scare fellow developers. Instead, you create an application that developers can be update, tweak, and manipulate without requiring major rewrites and aggressive re-factoring. The MVC architecture also will greatly improve your relationship with the marketing and business development departments, because they always want to make changes and with a well-designed application you can accommodate them.
The most effective way to build a PHP application based on the MVC design pattern is to leverage the power of a templating system such as Smarty for the Viewer, a PostgreSQL database as the Model, and object-oriented PHP classes as the Controller. This article demonstrates such an MVC framework by walking through the steps for building a simple newsreader called Amalgamate.
For the demo newsreader application, the Model will consist of a PostgreSQL database, leveraging its powerful PL/pgSQL language to encapsulate all the SQL statements inside the database using stored procedures. The advantages of using stored procedures are speed, decoupling the Model from the Controller, and manageability. See Listing 1
for the complete database schema for the Amalgamate database.
According to the PostgreSQL documentation: "With PL/pgSQL you can group a block of computation and a series of queries inside the database server, thus having the power of a procedural language and the ease of use of SQL, but with considerable savings because you don't have the whole client/server communication overhead."
Also, if you put all of your SQL in stored procedures, you will cleanly separate your Model component from the Controller. See Listing 2
for the stored procedures you will use in your PHP classes to interact with the data model.
Theoretically, the separation of your Model component from the Controller could allow you to easily swap your PostgreSQL database with, say, an Oracle database. However, planning to build an application with one database and then swapping that database with another one later on rarely works; that swap is never an easy task. The best reason to move your SQL into the database is because it makes for much cleaner code. When you need to make changes to your SQL, you don't have to go into your PHP classes and make bold modifications.
So that's your Model: a PostgreSQL database with stored procedures.