パッシブビュー
アプリケーション固有のすべての動作がコントローラーに抽出され、ウィジェットの状態がコントローラーによって完全に制御されるようにした画面とコンポーネント。
2006年7月18日
これは、2000年代半ばに行っていたエンタープライズアプリケーションアーキテクチャのさらなる開発に関する記事の一部です。残念ながら、それ以来、他の多くのことに気を取られて、それ以上取り組む時間がありませんでした。また、近い将来、時間を見つけることができるとも思えません。そのため、この資料はドラフト版であり、再び取り組む時間ができるまで、修正や更新を行う予定はありません。
リッチクライアントシステムを構築する際の長年の問題は、テストが複雑になることです。ほとんどのリッチクライアントフレームワークは、自動テストを念頭に置いて構築されていませんでした。これらのフレームワークをプログラムで制御することは、多くの場合非常に困難です。
パッシブビューは、ユーザーイベントへの応答を処理するだけでなく、ビューの更新もすべて行うコントローラーを使用することにより、UIコンポーネントの動作を最小限に抑えることで、この問題を解決します。これにより、ビューの問題のリスクをほとんどなくし、テストをコントローラーに集中させることができます。
仕組み
このパターンは、モデルビューコントローラーとモデルビュープレゼンターのもう1つのバリエーションです。これらと同様に、UIは、表示を処理するビューと、ユーザーのジェスチャーに応答するコントローラーに分割されます。パッシブビューの重要な変更点は、ビューが完全にパッシブになり、モデルから自身を更新する責任がなくなることです。その結果、すべてのビュロジックはコントローラーにあります。その結果、ビューとモデルの間には、どちらの方向にも依存関係はありません。
図1：ほとんどのMVCスタイルの構成とは異なり、パッシブビューでは、ビューとモデルの間に依存関係が発生しません。
通常の評価ウィンドウの例を見ると、ここでもビュー/コントローラーの分割が見られますが、今回はコントローラーがモデルをビューに表示する方法を判断するすべての作業を行います。テキストフィールドウィジェットはユーザーのジェスチャーを受け取りますが、クラシックなMVPムーブメントで、すぐにコントローラーに引き渡します。次に、コントローラーはモデルを更新し、モデルからのビューの再ロードを処理します。このロードアクションには、モデルから必要なすべてのデータをプルし、それを使用してウィジェットを更新することが含まれます。この例では、変更があるたびに完全にリロードする粗い粒度の同期を示しています。
図2：実際のテキストが編集されると、すべてのUI応答はコントローラーによって処理されます。
図3：評価例のクラス。
パッシブビューの主な推進力はテストであるため、UIフレームワークとの相互作用を必要とせずにコントローラーをテストできるように、ビューにテストダブルを使用することが有益な場合があります。これには、図4に示すように、中間ゲートウェイを設定する必要があります。これは、監視コントローラーで使用するのと同じ手法です。監視コントローラーと同様に、ここではスタブを示していますが、これはモックを使用する良い機会でもあります。
いつ使用するか
パッシブビューを使用する主な理由は、テスト容易性を向上させるためです。ビューがコントローラーのダムスレーブに減らされると、ビューをテストしなくてもリスクはほとんどありません。コントローラーは、UI環境の外で実行およびテストできます。実際、ビューにテストダブルを使用する場合は、UIクラスを利用できるようにする必要さえありません。
パッシブビューは、テストに役立つようにビューを十分に謙虚にする唯一の方法ではありません。プレゼンテーションモデルと監視コントローラーはどちらも妥当な代替案です。パッシブビューがこれら2つよりも優れている点は、両方の代替案でビューが同期作業の一部を行う必要があり、その結果、パッシブビューよりもテストできない動作が増えることです。この違いが重要かどうかは、判断に委ねられます。
パッシブビューのもう1つの利点は、非常に明確なメカニズムであることです。オブザーバーメカニズムや宣言型マッピングへの依存はほとんどありません。これにより、何が起こっているかを確認するためにコードを読みやすくなります。特に、問題が発生したときにデバッグしようとしている場合に役立ちます。