Building Object-Oriented Database Interfaces in PHP: Processing Data through Data Access Objects

Introduction

As websites evolved from simple linked regular HTML files to full-blown dynamic applications, where a database is the real workhorse for storing and delivering huge amounts of data, data accessing became a critical and sometimes hard to maintain process. Particularly, when working with a language such as PHP, designed to offer a friendly learning curve for building "quick and simple" applications, the issue is even more noticeable.

Certainly, it's not the same thing to update the logic of our simple user registration PHP script, as it is to maintain a 10,000 line PHP application, as you'll probably agree. In order to solve these difficulties and make maintenance as painless as possible, efforts have been underway to develop several tools aimed to fit in more demanding environments when building large database-driven applications. At first glance, these tools can be categorized in two general groups:

• Database Abstraction
  
• (X)HTML Generation

The first group covers a large variety of tools, targeted specifically to abstracting all of the processes involved in database access routines, which allows for more flexibility and portability in working with different database systems.

The second group may include several template tools, often developed as a set of classes that separate the application logic from the (X)HTML display logic. While both categories offer to developers different levels of complexity according to application requirements, they boost significantly the development process, by encouraging code reusability and extendibility.

However, let's forget for a while the second group and focus our attention on the first one. Particularly in large applications, an object-oriented solution is frequently used to manage all of the database access operations. The big picture seems to be good enough to satisfy most of data accessing requirements. But, there is a drawback to this approach. Most of the time, SQL statements are hard coded within the application, which implies some big headaches when an update is required.

As a response to this issue, a new category of tools has emerged from a couple of years ago, widely known as database interfaces. What's the point of having such tools? Database interfaces allow us to package DML statements, such as insert, update or delete commands within a class, providing a centralized mechanism for processing, verifying and securing data through one single access point inside the application.

Commonly, a database interface works in an intermediate level between the database abstraction layer and the (X)HTML generation layer. Having a class (or interface) that communicates the application logic with the database logic by using a unique shared point presents yet another major advantage: if the structure of the database has to be changed for any reason, it's a lot easier to modify the code of the DB interface than find and replace embedded SQL within hundreds of lines of code inside an application.

Thus, coding a DB interface is really an instructive experience that hopefully exposes a wide range of advantages and immediate benefits. Why not face the challenge? After all, it's going to be fun.

Through this series, I'll build up progressively a DB interface class that will create data access objects (DAO) from a database table, packaging several DML statements into one single structure, in this way allowing an efficient interaction between the application and the database system. Before you end up thinking of this like a bunch of buzzwords with no practical implementation, keep reading to find out more.