ドキュメント/ビュー アーキテクチャの代替手段
MFC アプリケーションでは、通常、ドキュメント/ビュー アーキテクチャを使用して、情報、ファイル形式、およびユーザーに対するデータの視覚的表現を管理します。 大部分のデスクトップ アプリケーションでは、ドキュメント/ビュー アーキテクチャが適切で効率的なアプリケーション アーキテクチャです。 このアーキテクチャでは、データを表示から分離し、ほとんどの場合、アプリケーションが簡略化され、冗長コードが削減されます。
ただし、ドキュメント/ビュー アーキテクチャは、特定の状況では適切ではありません。 次のような例を考えてみてください。
Windows 用に C で記述されたアプリケーションを移植する場合、ドキュメント/ビューのサポートをアプリケーションに追加する前に、ポートを完了する必要があります。
軽量ユーティリティを作成している場合は、ドキュメント/ビュー アーキテクチャを使用せずに実行できる場合があります。
元のコードでデータ管理とデータ表示が既に混在している場合、2 つを分離する必要があるため、ドキュメント/ビュー モデルにコードを移動するメリットはありません。 コードはそのままにしておいておく方が良い場合があります。
ドキュメント/ビュー アーキテクチャを使用しないアプリケーションを作成するには、MFC アプリケーション ウィザードの手順 1 の [ドキュメント/ビュー アーキテクチャ サポート] チェック ボックスをオフにします。 詳細については、「MFC アプリケーション ウィザード」を参照してください。
Note
MFC アプリケーション ウィザードによって生成されたダイアログ ベースのアプリケーションでは、ドキュメント/ビュー アーキテクチャは使用されません。そのため、ダイアログ アプリケーションの種類を選択すると、[ドキュメント/ビュー アーキテクチャのサポート] チェック ボックスは無効になります。
Visual C++ ウィザード、およびソース エディターとダイアログ エディターは、他のウィザードで生成されたアプリケーションの場合と同様に、生成されたアプリケーションを処理します。 このアプリケーションでは、ツール バー、スクロール バー、ステータス バーをサポートできます。また、About ボックスがあります。 アプリケーションはドキュメント テンプレートを登録せず、ドキュメント クラスは含まれません。
生成されたアプリケーションには、CWnd から派生したビュー クラス CChildView があります。 MFC は、アプリケーションによって作成されたフレーム ウィンドウ内にビュー クラスの 1 つのインスタンスを作成して配置します。 MFC では、アプリケーションのコンテンツの配置と管理が簡略化されるビュー ウィンドウの使用が引き続き適用されます。 このクラスの OnPaint メンバーに塗り分けコードを追加できます。 コードでは、フレームではなくビューにスクロール バーを追加する必要があります。
MFC によって提供されるドキュメント/ビュー アーキテクチャは、アプリケーションの基本的な機能の多くを実装する責任を負うため、プロジェクトに存在しなければ、ユーザーがアプリケーションの多くの重要な機能を実装する必要があります。
MFC アプリケーション ウィザードで提供される場合、アプリケーションのメニューには [ファイル] メニューの [新規] コマンドと [終了] コマンドのみが含まれます (〘 新しい コマンドは MDI アプリケーションでのみサポートされ、ドキュメント/ビューのサポートがない SDI アプリケーションではサポートされません)。生成されたメニュー リソースは、MRU (最近使用した) リストをサポートしません。
[ファイル] メニューの [開く] や [保存] など、アプリケーションでサポートされるコマンドのハンドラー関数と実装を追加する必要があります。 MFC では通常、これらの機能をサポートするコードが提供されますが、そのサポートはドキュメント/ビュー アーキテクチャに緊密にバインドされます。
アプリケーションのツール バーを要求した場合、ツール バーは最小限になります。
MFC アプリケーション ウィザードでは適切な MFC アーキテクチャが保証されるため、MFC アプリケーション ウィザードを使用して、ドキュメント/ビュー アーキテクチャを使用せずにアプリケーションを作成することを強く推奨します。 ただし、ウィザードの使用を避ける必要がある場合は、コード内のドキュメント/ビュー アーキテクチャをバイパスする方法がいくつかあります。
ドキュメントを未使用のアペンデージとして扱い、上記で提案したように、ビュー クラスにデータ管理コードを実装します。 ドキュメントのオーバーヘッドは比較的低いです。 1 つの CDocument オブジェクトでは、それ自体で少量のオーバーヘッドが生じ、さらに、
CDocumentの基底クラスである CCmdTarget および CObject のオーバーヘッドが少量生じます。 後者のクラスはどちらも小規模です。CDocumentで宣言:2 つの
CStringオブジェクト。3 つの BOOL。
1 つの
CDocTemplateポインター。ドキュメントのビューの一覧を含む 1 つの
CPtrListオブジェクト。
さらに、ドキュメントには、ドキュメント オブジェクト、そのビュー オブジェクト、フレーム ウィンドウ、およびドキュメント テンプレート オブジェクトを作成する時間が必要です。
ドキュメントとビューの両方を未使用のアペンデージとして扱います。 ビューではなく、フレーム ウィンドウにデータ管理と描画コードを配置します。 このアプローチは、C 言語プログラミング モデルに近い方法です。
ドキュメントとビューを作成する MFC フレームワークの部分をオーバーライドして、それらが作成されなくなるようにします。 ドキュメントの作成プロセスは、
CWinApp::AddDocTemplateの呼び出しから始まります。 アプリケーション クラスのInitInstanceメンバー関数からの呼び出しを排除し、代わりに、自分でInitInstanceにフレーム ウィンドウを作成します。 データ管理コードをフレーム ウィンドウ クラスに置きます。 ドキュメント/ビューの作成プロセスは、「ドキュメント/ビューの作成」に示されています。 これはさらに多くの作業が必要であり、フレームワークをより深く理解する必要がありますが、ドキュメント/ビューのオーバーヘッドから完全に解放されます。
「MFC: ドキュメントとビューを用いないデータベ0ス クラスの使用」には、データベース アプリケーションのコンテキストでのドキュメント/ビューの代替手法の例がより具体的に示されています。