15.1. What Is Persistence?

Whenever we run a program such as our SRS application, any objects (or value types, for that matter) that we declare and instantiate live in memory. When the program terminates, all of the memory allocated to the program is released back to the operating system, and the internal states of all of the objects created by the application are lost unless they have been saved—persisted—in some fashion.

Using various built-in I/O classes in the .NET Framework Class Library (FCL), C# provides a wealth of options with regard to persisting data.

• The programming elements found in the System.Data, System.Data.Odbc, System.Data.OleDb, System.Data.SqlClient, and System.Data.Oracle namespaces allow us to save data to an Open Database Connectivity (ODBC) database, an Object Linking and Embedding Database (OLE DB), or an Oracle database.

• We can output whole objects in a special binary form known as a C# serialized object, ideal for distributing objects over a network.

• We can also save information in a fairly straightforward, human-readable ASCII data format, as either of the following:

  • Hierarchically arranged data, such as with the Extensible Markup Language (XML) standard, in which we intersperse information—content—with custom tags that describe how the information is to be interpreted. For example, this simple example illustrates a Professor object with two Student advisees:

    <Professor>
      <name>Dr. Irving Smith</name>
      <id>123-45-6789</id>
      <title>Associate Professor</title>
      <advisee>

    
    

    <type>Student</type>
        <sname>Gerson Lopez</sname>
        <sid>987-65-4321</sid>
      </advisee>
      <advisee>
        <type>Student</type>
        <sname>Mary Jones</sname>
        <sid>999-88-7777</sid>
      </advisee>
    </Professor>

    
    

  • Simple tab- or comma-delimited record-oriented data, like this:

    222-22-2222  Gerson Lopez  Information Technology  Ph. D.  ART101-1

    
    

We'll be illustrating the most basic form of data persistence—record-oriented ASCII file persistence—in our SRS application code. However, many of the same design issues are applicable to the other forms of persistence as well, such as

• Hiding the details of how we persist an object: By encapsulating the details within an object's methods, the client code doesn't have to get bogged down with the details.

• Ensuring that whatever approach we take to persisting an object today is flexible: This allows us to swap out one approach and swap in another without making dramatic changes to our entire application.

• Providing exception handling when something goes amiss: Since persistence involves interacting with an external file system, database management system, and/or network, there are a lot of potential points of failure that are outside of the immediate program's control.

Before we discuss the two "sides" to the file-persistence "coin"—writing an object's state out to a file, and reading it back in again later—let's talk briefly about C# exception handling, which is an important (and necessary) part of writing code to read and write data.