[解決済み] MVPとMVC、その違いは何ですか？

質問

の先を見る場合 RAD (多くのツールが推奨しているユーザーインターフェイスの構築方法である モデル・ビュー・コントローラー , モデルビュープレゼンター そして モデル-ビュー-ビューモデル . 私の質問には3つの部分があります。

1. これらのパターンはどのような問題に対処するのですか？
2. どのように似ていますか？
3. どのように違うのですか？

どのように解決するのですか？

モデル-ビュー-プレゼンター

で MVP Presenter には、View の UI ビジネスロジックが含まれます。Viewからのすべての呼び出しは直接Presenterに委譲されます。PresenterはViewから直接切り離され、インターフェースを通じてViewと対話します。これは、ユニットテストにおいて View のモッキングを可能にするためです。MVP の共通の特徴として、多くの双方向ディスパッチが必要であることが挙げられます。例えば、誰かが "Save" ボタンをクリックすると、イベントハンドラは Presenter の "OnSave" メソッドにデリゲートします。保存が完了すると、Presenter はそのインタフェースを通じて View をコールバックし、View は保存が完了したことを表示できるようになります。

MVP は、WebForms で分離されたプレゼンテーションを実現するための非常に自然なパターンである傾向があります。なぜなら、ASP.NETランタイムによって、常にViewが最初に作成されるからです。あなたは 両方のバージョンについて詳しく見る .

2つの主要なバリエーション

パッシブビュー。 ビューは可能な限り間抜けで、ロジックをほとんど含んでいない。プレゼンターは、ビューとモデルと対話する仲介役です。ViewとModelは互いに完全に遮蔽されています。モデルはイベントを発生させることができますが、Presenter は View を更新するためにイベントを購読します。Passive View では直接のデータバインディングはなく、代わりに View がセッタープロパティを公開し、Presenter がそれを使用してデータを設定します。すべての状態は Presenter で管理され、View では管理されません。

• 長所：テスト容易性の最大化、ViewとModelの明確な分離
• 短所：すべてのデータバインディングを自分で行うため、作業が増える（たとえば、すべてのセッターのプロパティなど）。

コントローラを統括する。 Presenterは、ユーザーのジェスチャーを処理します。Viewはデータバインディングによって直接Modelにバインドします。このとき、ViewがバインドできるようにModelを渡すのはPresenterの仕事です。Presenter には、ボタン押下やナビゲーションなどのジェスチャーのためのロジックも含まれます。

• 長所：データバインディングを活用することで、コード量が削減される。
• Con: テスト可能な表面が少なくなる（データバインディングのため）。また、モデルと直接対話するため、ビューのカプセル化が少なくなる。

モデル・ビュー・コントローラー

での MVC アプリケーションのロード時など、何らかのアクションに応答してどのViewを表示するかを決定するのは、Controllerの役割です。これは、アクションがViewを経由してPresenterに至るMVPとは異なります。MVC では、View でのすべてのアクションは、アクションとともに Controller への呼び出しに関連します。Webでは、各アクションはURLへの呼び出しを含み、その反対側には応答するControllerがあります。そのControllerが処理を完了すると、正しいViewが返されます。アプリケーションのライフサイクルを通じて、このような流れが続きます。

    ビューでの動作
        -コントローラへの呼び出し
        -コントローラのロジック
        -> コントローラはビューを返します。

MVCのもう一つの大きな違いは、ViewがModelに直接バインドされないことです。ビューは単にレンダリングするだけで、完全にステートレスです。MVCの実装では、通常、Viewの背後のコードにロジックを持たせることはありません。これは、View が Presenter に委譲されない場合、決して呼び出されないため、絶対に必要である MVP とは異なります。

プレゼンテーションモデル

もう一つのパターンとして プレゼンテーションモデル パターンです。このパターンでは、Presenterは存在しない。その代わり、Viewは直接Presentation Modelにバインドします。プレゼンテーションモデルは、Viewのために特別に作られたモデルです。これは、このモデルが、ドメインモデルには決して置かれない、分離概念の違反となるプロパティを公開できることを意味します。この場合、Presentation Modelはドメインモデルにバインドされ、そのモデルから来るイベントをサブスクライブすることができます。そして、ViewはPresentation Modelから来るイベントを購読し、それに応じて自身を更新します。Presentation Modelは、ビューがアクションを呼び出すために使用するコマンドを公開することができます。このアプローチの利点は、PMがビューの全ての動作を完全にカプセル化するため、本質的にコードビハインドを完全に取り除くことが出来るということです。このパターンはWPFアプリケーションで使用するための非常に強力な候補であり、次のようにも呼ばれます。 モデル-ビュー-ビューモデル .

があります。 プレゼンテーションモデルに関するMSDN記事 のセクションと WPFのためのコンポジットアプリケーションガイダンス (旧プリズム)について 分離されたプレゼンテーションのパターン