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コンポーネントがユーザー入力を自分で処理しないようにすることはできますか？そして、「自分で処理する」とはどういう意味ですか？

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

• ユーザー入力はコントローラーによって処理されます
• コントローラーがモデルを更新します
• モデルはビュー/ユーザーインターフェイスを更新します

           +---+
      +----| V |<----+
user  |    +---+     | updates
input |              |
      v              |
    +---+          +---+
    | C |--------->| M |
    +---+ updates  +---+

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

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

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

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

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

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

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

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

• もっと努力が必要です。
• プレゼンターは、維持不可能な「神のクラス」に簡単に変換できます。
• アプリケーションには単一のMVP軸ではなく、複数の軸があります。ユーザーインターフェイスの各画面/ウィンドウ/パネルに1つです。これにより、アーキテクチャが簡素化されるか、恐ろしく複雑になりすぎます。

MVPでは、プレゼンターがMVCのコントローラーを置き換えます。2つの違いは、プレゼンターがビューを直接操作することです。これは、主にイベント駆動型（Windowsフォームなど）のUIフレームワーク用に設計されており、MVVMパターン（WPFなど）に役立つリッチデータバインディングを強力にサポートしていません。そうでなければ、ビューステートを管理し、バッキングモデルを更新するための多くのロジックがビュー自体にあります。