Building Object-Oriented Database Interfaces in PHP: Abstracting Database Tables (
Page 1 of 6 )
Welcome to part two of the series "Building Object-Oriented Database
Interfaces in PHP." In the previous article, I offered complete coverage of
the role that database interfaces play in Web applications, highlighting the
immediate benefits of having a centralized mechanism for accessing, processing
and verifying data, within an object-oriented environment. The "DBIGenerator"
class I showed for demonstration purposes in the first article doesn't scale
well in real applications. In this article, we will start solving its problems
with a revamped version of the class.Introduction
Without having to necessarily mess up things with some concepts inherent to theory, we might generally conceive database interfaces as a logical representation coded within a class of a database table, where each table field is represented as a class data member. By following this generic rule on a given database table, we're able to build programmatically a class that contains all of the core DML statements required to manipulate table rows, using the methods provided by the class, in this way acting as single access points to the table data.
Stepping back to the first article, I've shown a "DBIGenerator" class that quickly creates DB interface classes, spawning the corresponding objects to provide access to a given database table. As you probably remember, this class doesn't scale well in real applications, since it works with a hard-coded database table and fields, thereby limiting significantly its flexibility and portability.
In order to solve these relevant issues, this second part will be the starting point for defining a revamped version of the "DBIGenerator" class, which, as we'll see in short order, will be powerful enough to be implemented successfully in the creation of DB interfaces.
Confronted with this scenario, it's time to put our coding abilities to the test. Let's go!
