ドキュメント/ビュー アーキテクチャ

皆さん、こんにちは。Dr.テトランです。

さて、ここらでTetra21クライアントの根幹を成すDocument/View Architecture(ドキュメント/ビュー アーキテクチャ)について簡単に説明します。

 

ウィンドウズプログラムは、表示したいデータをスクリーンに書き込めば良いコンソールプログラムと違い、システムの要求に答えていつでもすばやくビューを再描画する必要が有ります。

そこで、ウィンドウオブジェクトを構成するのに、データを保持し必要な処理を施すドキュメントクラスとそれを表示するためのビュークラスに分けたものが、ドック&ビューアーキテクチャです。

実は、ウィンドウズと複数形の表現で解るようにビューは複数ありえるわけですから、それを入れる(親になる)フレームウィンドウクラス(複数可)も必要です。

更に、MDIの場合はこのMDIフレームが複数になるのが普通です。

前節まで、表ブラウザ基底クラスだの見積書クラスだの帳票クラスだのと簡略して言ってきましたが、正確にはそれぞれがドキュメント・ビュー・フレームの各クラス群で構成されています。

 

Tetra21クライアントのクラス継承図を付録として添付してありますので参考にしてください。

勿論、圧倒的多数を占めるそれ以外のクラス(その殆どがダイアログUI)は除いています。

 

普通のアプリケーションでは、個々のドキュメントインスタンスは独立していますが、Tetra21ではサーバを通して間接的に、あるいは先の帳票ドキュメントの様に直接関与(リンク)しています。

直接関与しているものには、他に見積書と検討表、工種組換シートがあります。

こうした関連性から、Tetra21クライアントのMDIは相互作用を前提にした動作になっています。

先ほど「表示するためのビュークラス」と簡単に述べましたが、このビュークラスのコーディング1つでプログラムの応答性能(機能ではありません)が決まってしまいます。

別に、マウスやキーボードインターフェースが必要であること(こちらも大事な実装ですが)を指している訳ではありません。

実はウィンドウズシステムは、再描画が必要なウィンドウに対しては、描画域に合わせた描画マスクを用意した上で、外郭の矩形情報を伴って描画メッセージを送ります。

受け取ったビューは、描画に関与するドキュメントだけを処理対象として、マスク内で背景とデータの描画を行うようにします。

 

また、自身が再描画要因を作る場合もあります。

 

例えばサイズの変更や、データ変更をビューに反映させる時がそうです。

この場合、再描画領域が最小になる工夫と、「ちらつき」を防ぐために、背景を温存させるような配慮が大切です。(何れも関連メソッドのオーバーライドが必要)

 

Tetra21クライアントでは、場合によってはイレースバックグラウンドメッセージを無視して背景を書かずに、データと同時に書くことで、文字の「ちらつき」にも配慮しています。

 

 

このために、ディスプレイコンテキスト(画面)に直接書かずに、その部分と等価なメモリコンテキスト(メモリ)を作成し、そこに完全な描画を行った後に、一気にディスプレイコンテキスト(画面)にビットブリット(コピー)することもあります。

しかしながら、メニューバーやキャプション、MFCオブジェクトがそうなっていない(相変わらずイレースしてから書き込んでいる)のは残念です。

そう言う訳で、Tetra21ではビューやフレームウィンドウにMFCが用意した登録済みクラスは使っておりません。

(MFCフレームワークは、はっきり言って初心者向けです)

Comments are closed.