web-dev-qa-db-ja.com

MVCに対するMVPの改善点は何ですか？

Model-View-Controller（MVC） および Model-View-Presenter（MVP） パターンについて3日間読みました。そして、私を非常に悩ませている1つの質問があります。すでにMVCがあったときに、ソフトウェア設計者がMVPを発明したのはなぜですか？

彼らはどのような問題に直面しましたか、MVCは解決しなかった（またはうまく解決しなかった）が、MVPは解決できるでしょうか？ MVPが解決しようとしている問題はどれですか。

私はMVPの歴史と説明、またはMVCとMVPの違いについての記事をたくさん読んだことがありますが、私の質問に対する明確な答えはありませんでした。

私が読んだ記事の1つで、それは言われました：

次に、Model View Presenterに移ります。これは、最新のコンポーネントベースのグラフィカルユーザーインターフェイスに適用したときのMVCパターンの不十分さに対応したものです。最近のGUIシステムでは、GUIコンポーネント自体が、一部の中央コントローラーではなく、マウスの動きやクリックなどのユーザー入力を処理します。

だから、理解できませんが、実際には別の方法で、GUIコンポーネントがユーザー入力を単独で処理しないようにすることはできますか？そして、「自分で処理する」とはどういう意味ですか？

designdesign-patternsmvcmvp
50
Victor

MVCは概念的にエレガントです。

  • ユーザー入力はコントローラーによって処理されます
  • コントローラはモデルを更新します
  • モデルがビュー/ユーザーインターフェイスを更新する
           +---+
      +----| V |<----+
user  |    +---+     | updates
input |              |
      v              |
    +---+          +---+
    | C |--------->| M |
    +---+ updates  +---+

ただし、MVCのデータフローとイベントフローは循環的です。また、ビューには多くの場合、重要なロジック（ユーザーアクションのイベントハンドラーなど）が含まれます。これらの特性により、システムのテストが困難になり、保守が難しくなります。

MVPアーキテクチャは、コントローラーをプレゼンターに置き換えます。プレゼンターは、ビューとモデルの間を仲介します。これはシステムを線形化します：

       user input         updates
+---+ -----------> +---+ --------> +---+
| V |              | P |           | M |
+---+ <----------- +---+ <-------- +---+
        updates            updates

これには次の利点があります。

  • ロジック（イベントハンドラーやユーザーインターフェイスの状態など）をビューからプレゼンターに移動できます。

  • ユーザーインターフェイスは、ユーザーインターフェイスの状態を記述するため、プレゼンターの観点から単体テストを行うことができます。ユニットテスト内では、ビューをプレゼンターを呼び出すテストドライバーに置き換えます。

  • ユーザーインターフェイスはアプリケーションロジックから分離されているため、両方を独立して開発できます。

ただし、このアプローチにはいくつかの欠点もあります。

  • もっと努力が必要です。
  • プレゼンターは、保守不可能な「神のクラス」に簡単に変更できます。
  • アプリケーションには単一のMVP軸はありませんが、複数の軸があります。ユーザーインターフェイスの各画面/ウィンドウ/パネルに1つです。これは、アーキテクチャを単純化するか、ひどく複雑化する可能性があります。
64
amon

MVPでは、MVCのコントローラーがプレゼンターに置き換わります。 2つの違いは、プレゼンターが直接ビューを操作することです。これは、主にイベント駆動型（Windowsフォームなど）であり、MVVMパターン（WPFなど）に適した豊富なデータバインディングを大幅にサポートしないUIフレームワーク用に設計されています。それ以外の場合、ビューステートを管理し、バッキングモデルを更新するためのロジックの多くは、ビュー自体にあります。

6
Michael Brown