Caching Result Sets in PHP: The Barebones of a Caching Class

Introduction

This is the third chapter of the series “Caching result sets in PHP.” Welcome back. If you’ve been traveling the procedural road within your PHP applications for a while, I hope that the result set caching solution developed in the second part of this series has been useful enough for you to start building an expandable caching system.

As mentioned in previous articles that belong to this series, a procedural caching solution is potentially well-suited for small and even medium-sized applications. However, when we make a step forward to building large projects, the panorama might dramatically change, as more complex development approaches are needed.

As you probably know, an object-oriented approximation is definitely a better solution, particularly when an application can be conceived as a set of well-defined and “pluggable” layers, where each one of them plays a specific role within the overall development context.

Based on the key concepts indicated above, this third part of the series will be focused mainly on developing an object-based extensible caching solution, in order to take advantage of the inherent benefits related to caching results sets. In this way, PHP applications may run faster, by reducing the additional overload introduced on the server when multiple database connections are established, or many resource-consuming SQL queries are performed on a frequent basis.

Since the object-oriented caching approximation is strongly based on a well-structured relationship between several PHP classes, hopefully the whole experience will be instructive for putting into practice different core concepts inherent to object interaction, such as aggregation and composition. If you have some small gaps within your background related to these topics, this article might help you fill them in.

Having detailed the scenario, the challenge is now right before us. Want to try a little bit more? Fine. Let’s go!