Chapter 11 -- Persistence

[Previous] [Next]

Chapter 11

An object is usually created to play a part within the context of an application or to provide some service to a group of applications. If the object has an internal state, programmers might want to save the object's state to nonvolatile storage for later restoration. For example, Microsoft ActiveX controls placed on a container such as Microsoft Visual Basic will have the same properties after closing the container and reopening it (barring catastrophic failure). As with Visual Basic, most desktop applications provide a means of saving their content to a file, database, or other nonvolatile medium. In the past, you might have written such applications without using COM components, streaming the important data and configurations to files in proprietary formats. At that time, the semantics of persistence were homegrown and application specific. Patterns for persistence have since evolved and have been incorporated into the development libraries and technologies we use today. MFC introduced a convenient way for programmers to save instances of C++ objects (with their states) to persistent storage and then load them up again through its CArchive, CFile, and CObject classes. COM specifies several persistence interfaces that define protocols for saving and loading objects and their states in binary or container-defined formats. These interfaces have a rich history that began with OLE Structured Storage. For a more thorough explanation of OLE Structured Storage, see Inside OLE by Kraig Brockschmidt (2nd ed., Microsoft Press, 1995).

In this chapter, we'll look at the ATL implementations of COM persistence interfaces and how they are enabled in ATL objects. We'll also step through some common scenarios with hosting applications to show these implementations in action.