Home | Overview | How Do I | FAQ | ODBC Driver List
Sometimes you might not want to use the framework’s document/view architecture in your database applications. This article explains:
Some applications have a distinct concept of a “document.” These applications typically load all or most of a file from storage into memory with a File Open command. They write the updated file back to storage all at once with a File Save or Save As command. What the user sees is a data file.
Some categories of applications, however, don’t require a document. Database applications operate in terms of “transactions.” The application selects records from a database and presents them to the user, often one at a time. What the user sees is usually a single current record, which may be the only one in memory.
If your application doesn’t require a document for storing data, you can dispense with some or all of the framework’s document/view architecture. How much you dispense with depends on the approach you prefer. You might:
If you use AppWizard to create your application, all of the database options produce applications with documents and views. Some of the options provide documents and views that omit unneeded document functionality. Here are the kinds of document/view support for each option.
AppWizard Options for Documents and Views
Option | View | Document |
None (no database support). | Derived from CView. | Full document support including serialization and New, Open, Save, and Save As commands on the File menu. |
Only include header files. | Derived from CView. | Same as None option. You can store CDatabase or CDaoDatabase and/or CRecordset or CDaoRecordset objects in your document or your view. |
A database view, without file support. | Derived from CRecordView or CDaoRecordView. | Document does not support serialization or the New, Open, Save, and Save As commands. You can use it to store your CRecordset or CDaoRecordset and to coordinate multiple views. |
Both a database view and file support. | Derived from CRecordView or CDaoRecordView. | Full document support, including serialization and document-related File menu commands. Use serialization for special purposes, such as storing user profile information. |
For a discussion of using the AppWizard options “A database view, without file support” and “Both a database view and file support,” see Applications with Minimal Documents.
For a discussion of writing applications with no document, see Applications with No Document.
For a discussion of alternatives to serialization, and alternative uses for serialization, see the article Serialization: Serialization vs. Database Input/Output.
AppWizard has two options that support form-based data-access applications. Each option creates a CRecordView-or CDaoRecordView derived view class and a document. They differ in what they leave out of the document.
Select the AppWizard database option “A database view without file support” if you don’t need document serialization. The document serves the following useful purposes:
This usage parallels ordinary document concepts: the document “stores” the data — or, in this case, a set of records — and the view is a view of the document.
If multiple views show the same data, you can use the CDocument::UpdateAllViews member function to coordinate updates to all views when any view changes the data.
You’ll usually use this option for simple form-based applications such as the Enroll tutorial application. AppWizard supports a convenient structure for such applications automatically.
Select the AppWizard database option “Both a database view and file support” when you have an alternative use for the document-related File menu commands and document serialization. For the data-access portion of your program, you can use the document in the same way as described in A Document Without File Support. You can use the document’s serialization capability, for example, to read and write a serialized user profile document that stores the user’s preferences or other useful information. For more ideas, see the article Serialization: Serialization vs. Database Input/Output.
AppWizard supports this option, but you must write the code that serializes the document. Store the serialized information in document data members.
You might sometimes want to write an application that uses neither documents nor views. Without documents, you store your data (such as a CRecordset or CDaoRecordset object) in your frame-window class or your application class. Any additional requirements depend on whether the application presents a user interface.
If you have a user interface (other than, say, a console command-line interface), your application draws directly into the frame window’s client area rather than into a view. Such an application doesn’t use CRecordView, CDaoRecordView, CFormView, or CDialog for its main user interface (but it will normally use CDialog for ordinary dialogs).
AppWizard doesn’t support creating applications without documents, so you must write your own CWinApp-derived class and, if needed, also create a CFrameWnd or CMDIFrameWnd class. Override CWinApp::InitInstance and declare an application object as
CYourNameApp NEAR theApp;
The framework still supplies the message-map mechanism and many other features.
Some applications need either no user interface or only a minimal one. For example, suppose you’re writing:
Because there is no document that owns the CRecordset or CDaoRecordset object, you’ll probably want to store it as an embedded data member in your CWinApp-derived application class. Alternatives include: