Choosing the Right Strategy: Hand-Made or Prefab Classes
So far in this book we have tried to take advantage of preexisting implementations in PEAR whenever possible. I have never been a big fan of reinventing the wheel, and in general, a class that is resident in PEAR can be assumed to have had more edge cases found and addressed than anything you might write from scratch. PEAR has classes that provide caching functionality (Cache and Cache_Lite), but I almost always opt to build my own. Why? For three main reasons:
Customizability The key to an optimal cache implementation is to ensure that it exploits all the cacheable facets of the application it resides in. It is impossible to do this with a black-box solution and difficult with a prepackaged solution. Efficiency Caching code should add minimal additional overhead to a system. By implementing something from scratch, you can ensure that it performs only the operations you need. Maintainability Bugs in a cache implementation can cause unpredictable and unintuitive errors. For example, a bug in a database query cache might cause a query to return corrupted results. The better you understand the internals of a caching system, the easier it is to debug any problems that occur in it. While debugging is certainly possible with one of the PEAR libraries, I find it infinitely easier to debug code I wrote myself.
|
There are a number of smart caching "appliances" on the market, by vendors such as Network Appliance, IBM, and Cisco. While these appliances keep getting smarter and smarter, I remain quite skeptical about their ability to replace the intimate knowledge of my application that I have and they don't. These types of appliances do, however, fit well as a commercial replacement for reverse-proxy caches, as discussed in Chapter 9.
|
|
