Serialization: Serialization vs. Database Input/Output

Home |  Overview |  How Do I |  Tutorial

This article explains when to use document objects and serialization for file-based input/output (I/O) and when other I/O techniques are appropriate — because the application reads and writes data on a per-transaction basis, as in database applications. If you don’t use serialization, you also won’t need the File Open, Save, and Save As commands. Topics covered include:

• Deciding how your application will handle input/output
  
  
• Handling the File menu in database applications

Deciding How to Handle Input/Output

Whether you use file-based I/O or not depends on how you respond to the questions in the following decision tree, which begins with the question:

Does the primary data in your application reside in a disk file?

1. Yes, the primary data resides in a disk file.

   Does the application read the whole file into memory on File Open and write the whole file back to disk on File Save?

2. Yes — this is the default MFC document case.

   Use CDocument serialization.

3. No — this is typically the case of transaction-based updating of the file.

   The MFC Advanced Concepts sample CHKBOOK is an example of this case. You update the file on a per-transaction basis and don’t need CDocument serialization.

4. No, the primary data doesn’t reside in a disk file.

   Does the data reside in an ODBC data source?

5. Yes, the data resides in an ODBC data source.

   Use MFC’s database support. The standard MFC implementation for this case includes a CDocument object that stores a CDatabase object, as discussed in the article What Is the MFC Database Programming Model?. The application might also read and write an auxiliary file — the purpose of the AppWizard “both a database view and file support” option. In this case, you’d use serialization for the auxiliary file.

6. No, the data doesn’t reside in an ODBC data source.

   Examples of this case: the data resides in a non-ODBC DBMS; the data is read via some other mechanism, such as OLE or DDE.

   In such cases, you won’t use serialization, and your application won’t have Open and Save menu items. You might still want to use a CDocument as a “home base,” just as an MFC ODBC application uses the document to store CRecordset objects. But you won’t use the framework’s default File Open/Save document serialization.

To support the Open, Save, and Save As commands on the File menu, the framework provides document serialization. Serialization reads and writes data, including objects derived from class CObject, to permanent storage, normally a disk file. Serialization is easy to use and serves many of your needs, but it may be inappropriate in many data-access applications. Data-access applications typically update data on a “per-transaction” basis. They update the records affected by the transaction rather than reading and writing a whole data file at once.

For general information about serialization, see the article Serialization (Object Persistence).

The File Menu in an MFC Database Application

If you create an MFC database application and don’t use serialization, how should you interpret the Open, Close, Save, and Save As commands on the File menu? While there are no style guidelines for this question, here are a few suggestions:

• Eliminate the File menu’s Open command entirely.
  
  
• Interpret the Open command as “open database” and show the user a list of data sources your application recognizes.
  
  
• Interpret the Open command as, perhaps, “open profile.” Retain Open for opening a serialized file, but use the file to store a serialized document containing “user profile” information, such as the user’s preferences, including his or her login ID (optionally excluding the password) and the data source he or she most recently worked with.

AppWizard supports creating an application with no document-related File menu commands. Select the “A database view, without file support” option on the database options page.

To interpret a File menu command in a special way, you must override one or more command handlers, mostly in your CWinApp-derived class. For example, if you completely override OnFileOpen (which implements the ID_FILE_OPEN command) to mean “open database”:

• Don’t call the base class version of OnFileOpen, since you’re completely replacing the framework’s default implementation of the command.
  
  
• Use the handler instead to display a dialog box listing data sources. You can display such a dialog by calling CDatabase::OpenEx or CDatabase::Open with the parameter NULL. This opens an ODBC dialog box that displays all available data sources on the user’s machine.
  
  
• Because database applications typically don’t save a whole document, you’ll probably want to remove the Save and Save As implementations unless you use a serialized document to store profile information. Otherwise, you might implement the Save command as, for example, “commit transaction.” See Technical Note 22 for more information about overriding these commands.