Up to now, we've had two rather unappealing choices: drink caffeinated coffee and risk the jitters, or drink decaf and miss out on that energy hit that got you drinking coffee in the first place. What we really want is some energy-boosting java with no side effects—we want the efficiency and benefits of using a directory-oriented document structure, but we want it all within the confines of a single file that is critical on an open system. In other words, we want a powerful file system implemented within a file. In fact, we want OLE Structured Storage. More specifically, we decide that compound files are the way to go: we can build the same directory and file hierarchy using storage and stream elements, as shown in Figure 7-6. We gain all the benefits of incremental access, automatic garbage collection, and free space management—as well as a number of other features—without doing much work at all. We preserve the single file notion that the end user has come to expect, yet we don't have to spend time on complex development efforts, giving us the opportunity to improve the product in other ways or to get it to market sooner. Wow! A great buzz with no jitters!
If you are implementing objects that require a persistent state, you will generally need to use storage and stream elements for storing object data, as described in Chapter 8. The client or container application that deals with persistent objects will then need to provide objects with the appropriate storage or stream elements. As we'll see, these elements need not come from a compound file and can be built on top of an application's private file format. But there are many advantages to using Compound Files directly, especially because future versions of Windows will use this sort of model as the native file system. Applications that store their data in compound files will integrate better with the rest of the system.
Figure 7-6.
Patron's storage scheme, using structured storage.