向こう側を見るとラド多くのツールが推奨するユーザーインターフェースの構築方法（ドラッグアンドドロップと設定）では、3つのデザインパターンと呼ばれるものに遭遇する可能性があります。モデル-ビュー-コントローラ、モデル ビュー プレゼンターそしてモデル-ビュー-ビューモデル私の質問は3つの部分から成ります。
- これらのパターンはどのような問題に対処しますか?
- それらはどのように似ているのでしょうか?
- それらはどう違いますか？
ベストアンサー1
モデル ビュー プレゼンター
MVPでは、プレゼンターにはビューの UI ビジネス ロジックが含まれています。ビューからのすべての呼び出しは、プレゼンターに直接委任されます。プレゼンターはビューから直接分離され、インターフェイスを介してビューと通信します。これにより、単体テストでビューのモックが可能になります。MVP の一般的な属性の 1 つは、双方向のディスパッチが多数必要になることです。たとえば、誰かが [保存] ボタンをクリックすると、イベント ハンドラーはプレゼンターの [OnSave] メソッドに委任します。保存が完了すると、プレゼンターはインターフェイスを介してビューをコールバックし、ビューは保存が完了したことを表示できます。
MVPは、Webフォームで分離されたプレゼンテーションを実現するための非常に自然なパターンです。その理由は、ビューが常にASP.NETランタイムによって最初に作成されるためです。両方の変種についてさらに詳しく知る。
2つの主なバリエーション
パッシブ ビュー:ビューは可能な限り単純で、ロジックはほとんど含まれていません。プレゼンターは、ビューとモデルと通信する仲介者です。ビューとモデルは完全に相互に保護されています。モデルはイベントを発生させる場合がありますが、プレゼンターはビューを更新するためにイベントをサブスクライブします。パッシブ ビューでは、直接のデータ バインディングはなく、代わりに、プレゼンターがデータの設定に使用するセッター プロパティがビューで公開されます。すべての状態は、ビューではなくプレゼンターで管理されます。
- 利点: テスト可能性が最大限に高まり、ビューとモデルが明確に分離される
- 欠点: すべてのデータ バインディングを自分で行うため、作業量が増えます (たとえば、すべての setter プロパティ)。
監視コントローラー:プレゼンターはユーザーのジェスチャを処理します。ビューはデータ バインディングを通じてモデルに直接バインドします。この場合、モデルをビューに渡してバインドできるようにするのはプレゼンターの役割です。プレゼンターには、ボタンの押下やナビゲーションなどのジェスチャのロジックも含まれます。
- 利点: データ バインディングを活用することで、コードの量が削減されます。
- 欠点: テスト可能なサーフェスが少なくなります (データ バインディングのため)。また、モデルと直接通信するため、ビューのカプセル化が少なくなります。
モデル-ビュー-コントローラ
MVCでは、コントローラーは、アプリケーションのロード時など、あらゆるアクションに応じてどのビューを表示するかを決定する役割を担います。これは、アクションがビューを経由してプレゼンターにルーティングされる MVP とは異なります。MVC では、ビュー内のすべてのアクションは、アクションとともにコントローラーへの呼び出しと相関しています。Web では、各アクションには URL への呼び出しが含まれ、その反対側には応答するコントローラーがあります。そのコントローラーが処理を完了すると、正しいビューを返します。シーケンスは、アプリケーションの存続期間中、このように続きます。
ビュー内のアクション
-> コントローラーへの呼び出し
-> コントローラーロジック
-> コントローラーはビューを返します。
MVC に関するもう 1 つの大きな違いは、View が Model に直接バインドされないことです。View は単にレンダリングするだけで、完全にステートレスです。MVC の実装では、View のコード ビハインドには通常ロジックはありません。これは、View が Presenter に委任しないと呼び出されないため、MVP ではロジックが絶対に必要となるのとは対照的です。
プレゼンテーションモデル
注目すべきもう 1 つのパターンは、プレゼンテーション モデルパターンです。このパターンにはプレゼンターはありません。代わりに、ビューはプレゼンテーション モデルに直接バインドします。プレゼンテーション モデルは、ビュー専用に作成されたモデルです。つまり、このモデルは、ドメイン モデルに配置することは関心の分離に違反するため、決して配置しないプロパティを公開できます。この場合、プレゼンテーション モデルはドメイン モデルにバインドされ、そのモデルからのイベントをサブスクライブできます。次に、ビューはプレゼンテーション モデルからのイベントをサブスクライブし、それに応じて更新します。プレゼンテーション モデルは、ビューがアクションを呼び出すために使用するコマンドを公開できます。このアプローチの利点は、PM がビューのすべての動作を完全にカプセル化するため、基本的にコード ビハインドを完全に削除できることです。このパターンは、WPF アプリケーションで使用するための非常に有力な候補であり、モデル-ビュー-ビューモデル。
そこにはプレゼンテーション モデルに関する MSDN の記事そして、WPF の複合アプリケーション ガイダンス（旧プリズム）について分離されたプレゼンテーションパターン