Programming .NET Components, 2nd Edition

Chapter 9. Serialization and Persistence

In a component-oriented application, the component instances (the objects) maintain their state (the object’s member variables) in memory and apply business logic on that state. But how is this state initially generated, and what happens to it when the application shuts down or when the user selects Save? In almost every application, object states aren’t created out of thin air when the application starts. An application typically loads some file containing data and converts the information in the file into live objects. Similarly, when the application shuts down, the object state is saved (or, persisted) to a file. Traditionally, this is referred to as serialization and deserialization . These terms were originally coined to describe a simple binary dump of an object’s state to a file and its subsequent recovery. In such cases, the application wrote the state of the object serially, one bit at a time. When the application later read the information, it processed the information serially in exactly the same order into a memory location and associated that location with an object.

Classic object-oriented programming didn’t offer much in the way of implementing serialization. Consequently, not only did developers spend much of their valuable time on mundane serialization code instead of adding business value to their applications, but the resulting solutions were proprietary and singular. There was no generic way for two applications to share ...