Refactoring the MySQL Abstraction Class with the Active Record Pattern

Introduction

When it comes to implementing the active record design pattern with PHP, in most cases data mapper objects are used to interact with a certain number of databases. Generally, these objects act like a single, unified interface that can be used to perform CRUD tasks (Create, Retrieve, Update, Delete) on mapped tables.

This schema obviously permits you to achieve a high level of SQL abstraction, since executing the mentioned tasks against a selected database table doesn’t require directly writing any SQL statements. All the business logic is handled behind the scenes by the objects in question.

However, it’s perfectly feasible to apply the active record pattern by using just a database accessing class, and still get an acceptable grade of SQL abstraction, particularly when it comes to inserting, updating and deleting records of a specific database table.

Now, returning for a moment to the topics discussed in the last installment, I left off explaining how to build a simple MySQL abstraction class, which had the ability to fetch a predefined number of records from a sample “users” MySQL table by using a LIMIT clause. In this particular case, a concrete method within the class was responsible for performing this task, without the need to code explicitly any SQL statements from outside the class.

As I stated in the end of the tutorial, however, some methods of this sample class implement redundant business logic, and as a consequence it’s necessary to refactor them to fix this issue in a quick and simple manner. Thus, in the next few lines I’ll be explaining how to accomplish this process progressively, and as always, accompanied by the corresponding code samples.

Now, it’s time to start modifying the signature of this MySQL abstraction class to make it more efficient and compact. Let’s go!