Login

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

While procedural caching may be well-suited for small and even medium-sized applications, the picture changes for large projects. That’s when object-oriented approaches come into their own. This article focuses on developing an object-based extensible caching solution.

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!

Before jumping directly into the process of writing some PHP classes and implementing an object-based caching system, let’s take a brief look at the procedural method developed in the second part of this series, which properly carries out the cache generation based on a content change trigger. The full code for this solution is listed as follows:

Coding an example for putting this caching system to work is really easy and fairly understandable. Seemingly, the script is doing its thing without major problems. However, for large environments, this solution simply doesn’t scale properly. Despite the fact that we’ve built a couple of functions that hide all of the internal processing to read and write the cache file, as well as run SELECT statements, the overall code is not so easy to follow. Moreover, we’re not delineating clearly the tasks of each function, which results in hard-to-maintain code and reduced portability.

Thus, in order to address properly these limitations, we need to look at an object-oriented approximation that allows us to rapidly implement a caching system in production environments, with minor modifications.

In the next section of this article, we’ll see how to develop an expansible result set caching class, which can be easily “plugged” into an existing application. Keep on reading, because it’s really worthwhile.

{mospagebreak title=The object-oriented solution: developing a result set caching class}

Prior to developing the caching class, we need to specify some important prerequisites. First, the class will implement a time expiry-based caching trigger. However, this is not a big limitation, since a different caching trigger might be developed without making significant changes to the source code. This will be left as a possible additional feature.

Second, the class will aggregate a MySQL abstraction object, for having database connectivity within its scope, so if you’re not familiar with the concept of aggregation, feel free to visit Object Interaction in PHP Introduction to Aggregation part 1, where I’ve written an article series that discusses the topic in detail.

Finally, since the source code is highly portable, in a future article the whole set of classes will be updated to PHP 5, aimed specifically at those developers working with the latest version of PHP.

All right, having stated these few disclaimers, it’s time to look at the result caching class, which, not surprisingly, I’ve called “Cache.” Its definition is as follows:

At first glance, and looking at the data member declaration, we can see that the “Cache” class aggregates a MySQL object and a “Result” object, where the first one is directly passed to the constructor. So, if you might want to see the complete code for each class involved, don’t feel concerned about this. We’ll see in turn, the proper definition for all of the additional classes that we’re working with.

For the moment, let’s focus our attention on the code for the “Cache” class, which will be explained in detail over the next few lines.

{mospagebreak title=Caching with class: a deeper look at the “Cache” class}

Certainly, there are many trusted caching classes on the Web, ready to be quickly implemented within an application. Regarding this situation, I’m definitely not trying to market my caching class. Personally, I think that the structure of the class is extensible and points out its functionality to perform a specific task. Very often I’ve seen classes that are packaged with a wealth of methods that don’t maintain a strict relationship with the objective for which these classes were created.

In this case, since the main goal of the class is to cache results sets in a file, its methods are set up specifically to perform related tasks. Any other processes, such as database handling, query execution and error handling, are delegated to other classes. Thus, the reason for implementing object aggregation inside the class should become clear now.

But, I promised a detailed explanation of each method, so let’s start looking at the constructor. The method takes the following parameters: $mysql, which represents a reference to a MySQL object, in order to provide the class with the ability to handle database operations. Then, the second argument, $expiry means the expire time expressed in seconds for the cache to be considered valid, while the third parameter, $cacheFile, simply specifies the name of the cache file where the result set will be stored.

At times, it’s useful to give default values for some parameters, thus I’ve done so for the expire time and the cache file. The constructor assigns the values passed directly to it as data members, like this:

The only thing to notice here is the creation of the $this->data array. This property represents the result set to be returned either by a regular query or obtained directly from the cache file. We’ll see more about it in a few moments.

As for the procedural approach, the “readCache()” and “writeCache()” private methods are the actual class’ workhorses, since they read and write the cache file in accordance with the class logic. The “writeCache()” method looks slightly more complex, as you can see in the listing below:

This method opens or tries to create a cache file, then gets a result set that is properly serialized. Finally, it writes the serialized data to the cache file, and returns the results for further processing.

Notice that each potential error condition is handled by the “isError()” method that belongs to the MySQL wrapping class. Errors are handled in this way for keeping the code more readable. However, I strongly recommend that you delegate any possible errors to another object that provides a centralized error handling mechanism. Programmers that have already worked with exceptions in PHP 5 probably know that they provide a useful method for efficiently handling errors by using one single point within an application.

As you can see, file locking is implemented at a basic level, but this method may not work properly for different operating systems. Just make sure that you’re working with a file locking method that is supported by the operating system on which the application will be run.

The only thing left to be reviewed is the way that each table row is retrieved. Please see that the method uses the “fetchRow()” method to fetch rows. However, the method is taken as a “temporary loan,” since it belongs to the $this->result object. Once again, we’re using aggregated objects for performing some tasks that are not strictly related to the “Cache” class itself.

If this sounds rather confusing, the relationship between classes will become clear when we look at the complete source code for each class used in this series. By now, it’s more than enough for explaining the logic of the caching class.

As we’ve seen, the other relevant method is “readCache()”, which reads the cache file, and returns the unserialized data array for being processed. This is best understood by showing its short definition:

Okay, there are still some methods that need to be properly explained, in order to fully understand how the class works. So, join me in the next section to learn more about their functionality.

{mospagebreak title=More class methods in detail: ending up the round}

The next method to be reviewed is the “query()” method. While its definition is extremely simple, its relevance within the class is considerable. Notice that this method accepts a SELECT statement as a parameter, and directly determines when the result set will be updated, thereby forcing a new cache file generation.

If the cache file is found not to be valid, then the query is run, the data is returned from the database and written to the cache file. Otherwise, the data is returned from the cache. These operations are best described looking at the method’s definition:

As you can see, the cache update triggering process is internally handled by the “isValid()” private method, because it checks whether the data will be obtained from MySQL or directly from the cache file, as shown in the following lines:

Here we have an interesting topic that needs to be properly highlighted. Note that the above method is encapsulating the logic for resolving how to trigger the caching system. In this specific case, we’re using a time expiry based caching trigger. However, we’re able to refactor this method in order to handle a different caching strategy. This single feature implies a greater level of flexibility, since several caching triggers might be used either as one single method or as a combination of them.

Finally, the rest of the class methods speak for themselves. The “fetchRow()” method fetches a row from the cached data, handy for returning a row at a time, while the “fetchAll()” method returns all of the cache rows. If we need to count the total number of cache rows, the “countRows()” method easily accomplishes this task.

Of course, there are some additional methods that might be added to the class for improving its functionality. As usual, feel free to play with the code and write your own methods.

By this point, our round up explaining all of the class methods has hopefully ended. So, let’s proceed to read the corresponding conclusions.

Summarizing

In this third part of the series, I’ve developed an expandable result set caching class that exposes different methods useful for programmatically manipulating cached data. Aside from exploring its structure in detail, I’ve demonstrated how different classes are aggregated to implement an efficient caching mechanism.

However, the big picture is still incomplete. We need to have a look at the rest of the classes that interact within the overall application. Thus, the next article will fully cover that part, in order to put all of the pieces together. Meanwhile, play with the code and add your own features to the caching class. See you in the next part!