MVPとMVCとは何ですか？違いは何ですか？

ユーザーインターフェイスを構築するRAD（ドラッグアンドドロップおよび構成）の方法を超えて検討すると、多くのツールは、Model-View-Controller、Model-View-Presenter、およびModel-View-ViewModelと呼ばれる3つの設計パターンに出くわす可能性が高いと考えています。私の質問には3つの部分があります。

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

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

でMVP、プレゼンターは、表示のためのUIのビジネスロジックが含まれています。ビューからのすべての呼び出しは、プレゼンターに直接委任します。プレゼンターもビューから直接切り離され、インターフェースを介してビューと通信します。これは、単体テストでビューのモックを可能にするためです。MVPの一般的な属性の1つは、多くの双方向ディスパッチが必要になることです。たとえば、誰かが「保存」ボタンをクリックすると、イベントハンドラーはPresenterの「OnSave」メソッドに委譲します。保存が完了すると、プレゼンターはインターフェイスを介してビューをコールバックし、ビューに保存が完了したことを表示できるようにします。

MVPは、Webフォームで個別のプレゼンテーションを実現するための非常に自然なパターンになる傾向があります。その理由は、ASP.NETランタイムによって常に最初にビューが作成されるためです。両方の亜種について詳しく知ることができます。

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

パッシブビュー：ビューは可能な限りダムであり、ロジックはほとんど含まれていません。プレゼンターは、ビューとモデルに話しかける仲介者です。ビューとモデルは互いに完全にシールドされています。モデルはイベントを発生させる可能性がありますが、プレゼンターはビューを更新するためにそれらをサブスクライブします。パッシブビューでは、直接のデータバインディングはありません。代わりに、ビューは、プレゼンターがデータを設定するために使用するセッタープロパティを公開します。すべての状態はビューではなくプレゼンターで管理されます。

• プロ：テスト可能性の面が最大です。ビューとモデルの明確な分離
• 欠点：すべてのデータバインディングを自分で行うので、多くの作業（たとえば、すべてのセッタープロパティ）。

監督コントローラー：プレゼンターはユーザーのジェスチャーを処理します。ビューはデータバインディングを介してモデルに直接バインドします。この場合、モデルをバインドしてビューに渡すのはプレゼンターの仕事です。プレゼンターには、ボタンを押す、ナビゲーションなどのジェスチャーのロジックも含まれます。

• メリット：データバインドを活用することで、コードの量が削減されます。
• 欠点：（データバインディングのために）テスト可能な表面が少なく、モデルと直接通信するため、ビューのカプセル化が少なくなります。

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

ではMVC、コントローラは、ビューは、アプリケーションの負荷を含む任意のアクションに応じて表示するかを決定する責任があります。これは、アクションがビューを介してプレゼンターにルーティングされるMVPとは異なります。MVCでは、ビュー内のすべてのアクションは、アクションとともにコントローラーへの呼び出しと関連付けられます。Webでは、各アクションには、反対側のコントローラーが応答するURLへの呼び出しが含まれます。コントローラーが処理を完了すると、正しいビューが返されます。シーケンスは、アプリケーションの存続期間中、そのように続きます。

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

MVCのもう1つの大きな違いは、ビューがモデルに直接バインドされないことです。ビューは単純にレンダリングされ、完全にステートレスです。MVCの実装では、通常、ビューはコードビハインドのロジックを持ちません。これは、ビューがプレゼンターに委任しないと呼び出されないため、絶対に必要なMVPとは逆です。

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

注目すべきもう1つのパターンは、プレゼンテーションモデルです。パターン。このパターンでは、プレゼンターは存在しません。代わりに、ビューはプレゼンテーションモデルに直接バインドします。プレゼンテーションモデルは、ビュー専用に作成されたモデルです。つまり、このモデルは、関心の分離に違反することになるため、ドメインモデルに配置できないプロパティを公開できるということです。この場合、プレゼンテーションモデルはドメインモデルにバインドし、そのモデルからのイベントをサブスクライブする場合があります。次に、ビューはプレゼンテーションモデルからのイベントをサブスクライブし、それに応じて自身を更新します。プレゼンテーションモデルは、ビューがアクションの呼び出しに使用するコマンドを公開できます。このアプローチの利点は、PMがビューのすべての動作を完全にカプセル化するため、分離コードを完全に削除できることです。Model-View-ViewModel。

あるプレゼンテーションモデルについてのMSDNの記事やセクションWPF用コンポジットアプリケーションのガイダンスについて（旧プリズム）分離プレゼンテーションパターンは、

これは、これらのデザインパターンの多くのバリアントの単純化しすぎですが、これは、2つの間の違いについて考える方法です。

MVC

MVP

私はこれについてしばらく前にブログに投稿し、2つの違いに関するTodd Snyderの優れた投稿を引用しています。

パターン間の主な違いは次のとおりです。

MVPパターン

• ビューはモデルとより疎結合です。プレゼンターは、モデルをビューにバインドする責任があります。
• ビューとの対話はインターフェースを介して行われるため、単体テストが容易になります
• 通常、プレゼンターマップを1対1で表示します。複雑なビューには複数のプレゼンターがいる場合があります。

MVCパターン

• コントローラは動作に基づいており、ビュー間で共有できます
• 表示するビューの決定を担当できます

それは私が見つけることができたウェブ上の最良の説明です。

コミュニケーションの流れを表すイラストはこちら

MVPは、必ずしもビューが責任を負うシナリオではありません（たとえば、TaligentのMVPを参照してください）。
「ただの見方だ」（プラグマティックプログラマー）と矛盾する反パターンではなく、パターン（担当の見方）として人々がまだこれを説教しているのは残念です。「これは単なるビューです」とは、ユーザーに表示される最後のビューがアプリケーションの二次的な問題であることを示しています。MicrosoftのMVPパターンは、ビューの再利用をはるかに困難にし、Microsoftの設計者が悪い習慣を奨励することを都合よく許します。

完全に正直に言うと、MVCの根本的な懸念はどのMVP実装にも当てはまり、違いはほぼ完全にセマンティックです。ビュー（データを表示する）、コントローラー（ユーザーの操作を初期化および制御する）、およびモデル（基になるデータやサービス）の間の関心の分離に従っている限り、MVCの利点を達成できます。 。あなたが利益を達成しているなら、あなたのパターンがMVC、MVP、または監督コントローラーであるかどうか本当に誰が気にしますか？唯一の本当のパターンはMVCのままですが、残りは単に異なるフレーバーです。

これらのさまざまな実装の数を包括的にリストしているこの非常にエキサイティングな記事を考えてみてください。それらはすべて基本的に同じことを行っていますが、少し異なります。

私は個人的に、MVPが最近何かが本当にMVCであるかどうかを論ずる意味論的偏見の間の議論を減らすため、またはMicrosoftの迅速なアプリケーション開発ツールを正当化するためのキャッチーな用語として最近再導入されたと思います。私の本のこれらの理由はどちらも、その存在を個別のデザインパターンとして正当化するものではありません。

MVP：ビューが担当しています。

ほとんどの場合、ビューはプレゼンターを作成します。プレゼンターはモデルと対話し、インターフェースを介してビューを操作します。ビューは、通常いくつかのインターフェイスを通じて、プレゼンターと対話することがあります。これは実装に帰着します。ビューでプレゼンターのメソッドを呼び出すか、またはビューにプレゼンターがリッスンするイベントを含めますか？つまり、ビューはプレゼンターについて知っています。ビューはプレゼンターに委任します。

MVC：コントローラーが担当しています。

コントローラーは、何らかのイベント/要求に基づいて作成またはアクセスされます。次に、コントローラーは適切なビューを作成し、モデルと対話してビューをさらに構成します。つまり、コントローラーはビューを作成および管理します。ビューはコントローラーのスレーブです。ビューはコントローラについて知りません。

MVC（Model View Controller）

入力は、ビューではなく、最初にコントローラーに向けられます。その入力は、ページを操作しているユーザーからのものである可能性がありますが、特定のURLをブラウザに入力しただけの場合もあります。どちらの場合も、一部の機能を開始するためにインターフェースされるコントローラーです。コントローラとビューの間には多対1の関係があります。これは、単一のコントローラーが、実行されている操作に基づいてレンダリングされる異なるビューを選択する可能性があるためです。コントローラからビューへの一方向の矢印に注意してください。これは、ビューがコントローラーについての知識や参照を持たないためです。コントローラはモデルをパスバックするので、ビューとそれに渡される期待されるモデルの間には知識がありますが、それを提供するコントローラには知識がありません。

MVP（モデルビュープレゼンター）

入力は、プレゼンターではなくビューから始まります。ビューと関連付けられたプレゼンターの間には1対1のマッピングがあります。ビューは、プレゼンターへの参照を保持します。プレゼンターは、ビューからトリガーされるイベントにも反応するので、プレゼンターはそれに関連付けられているビューを認識します。プレゼンターは、モデルに対して要求されたアクションに基づいてビューを更新しますが、ビューはモデルを認識しません。

より多くのためのリファレンス

質問に対する答えはたくさんありますが、両者を明確に比較する本当に簡単な答えが必要だと感じました。ユーザーがMVPおよびMVCアプリで映画名を検索するときに私が作成したディスカッションは次のとおりです。

ユーザー：クリッククリック…

表示：それは誰ですか？[ MVP | MVC ]

ユーザー：検索ボタンをクリックしただけで…

見る：わかりました、しばらくお待ちください... [ MVP | MVC ]

（プレゼンターの呼び出しを表示 | コントローラー …）[ MVP | MVC ]

表示：ちょっとプレゼンター | コントローラ、ユーザーが検索ボタンをクリックしただけですが、どうすればよいですか？[ MVP | MVC ]

プレゼンター | コントローラー：Hey View、そのページに検索キーワードはありますか？[ MVP | MVC ]

見る：はい、…ここに…「ピアノ」[ MVP | MVC ]

プレゼンター：おかげでビュー …その間、私はモデルで検索語を調べていますが、プログレスバーを見せてください[ MVPを | MVC ]

（プレゼンター | コントローラーがモデルを呼び出しています…）[ MVP | MVC ]

プレゼンター | コントローラー：ねえモデル、この検索キーワードに一致するものはありますか？：「ピアノ」[ MVP | MVC ]

モデル：Hey Presenter | コントローラー、チェックさせて…[ MVP | MVC ]

（モデルは映画データベースにクエリを作成しています…）[ MVP | MVC ]

（ しばらくして ... ）

-------------- MVPとMVCが分岐し始める場所です---------------

モデル：私はあなたのためのリストを見つけました。プレゼンター、ここではJSON "[{" name "：" Piano Teacher "、" year "：2001}、{" name "：" Piano "、" year "：1993}です。 ]」[ MVP ]

モデル：利用可能な結果がいくつかあります、コントローラー。インスタンスにフィールド変数を作成し、結果を入力しました。名前は "searchResultsList" [ MVC ]です。

（プレゼンター | コントローラのおかげでモデルとに戻って取得するビュー）[ MVP | MVC ]

プレゼンター：Viewをお待ちいただきありがとうございます。一致する結果のリストを見つけて、表示可能な形式で並べました：["Piano Teacher 2001"、 "Piano 1993"]。縦のリストでユーザーに示してください。また、進行状況バーを非表示にしてください[ MVP ]

Controller：Viewを待ってくれてありがとう、私はModelに検索クエリについて尋ねました。一致する結果のリストが見つかり、そのインスタンス内の「searchResultsList」という名前の変数に保存されたと述べています。そこから入手できます。また、進行状況バーを非表示にしてください[ MVC ]

表示：プレゼンターありがとうございました[ MVP ]

ビュー：「コントローラー」[ MVC ]に感謝します（ビューはそれ自体に疑問を投げかけています。モデルからユーザーにですか？映画の制作年を最初にするか、最後にするか...縦または横のリストにありますか？...）

興味があれば、私はここに Githubリポジトリを伴うアプリアーキテクチャパターン（MVC、MVP、MVVP、クリーンアーキテクチャなど）に関する一連の記事を書いています。サンプルはandroid用に作成されていますが、基本的な原則は任意のメディアに適用できます。

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

• MVC = Model-View-Controller

  1. 両方の表示パターン。これらは、モデル（ドメインオブジェクトと考える）、画面/ Webページ（ビュー）、およびUIの動作方法（プレゼンター/コントローラー）間の依存関係を分離します。
  2. 彼らは概念がかなり似ています、人々はプレゼンター/コントローラーを好みに応じて異なって初期化します。
  3. 違いに関するすばらしい記事はこちらです。最も注目すべきは、MVCパターンがビューを更新するモデルを持っていることです。

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

MVCは、ソフトウェアアプリケーションのアーキテクチャのパターンです。アプリケーションロジックを3つの別々の部分に分離し、モジュール性を促進し、コラボレーションと再利用を容易にします。また、アプリケーションをより柔軟にし、反復を歓迎します。アプリケーションを次のコンポーネントに分割します。

• データとビジネスロジックを処理するためのモデル
• ユーザーインターフェイスとアプリケーションを処理するためのコントローラー
• グラフィカルユーザーインターフェイスオブジェクトとプレゼンテーションを処理するためのビュー

これをもう少し明確にするために、簡単な買い物リストアプリを想像してみましょう。必要なのは、今週購入する必要がある各アイテムの名前、数量、価格のリストです。以下では、MVCを使用してこの機能の一部を実装する方法について説明します。

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

• モデルビュー（ユーザーインターフェース）に表示されるデータです。
• ビュープレゼンターに表示データ（モデル）とルートユーザコマンド（イベント）がそのデータに作用することのインタフェースです。通常、ビューにはプレゼンターへの参照があります。
• プレゼンターは（MVCコントローラによって果たされる）「仲介人」であり、ビューとモデルの両方への参照を有します。「モデル」という言葉は誤解を招くものであることに注意してください。むしろ、モデルを取得または操作するビジネスロジックである必要があります。例：データベーステーブルにユーザーを格納するデータベースがあり、ビューがユーザーのリストを表示したい場合、プレゼンターはリストからクエリを行うデータベースビジネスロジック（DAOなど）への参照を持ちます。ユーザーの。

簡単な実装のサンプルを見たい場合は、この GitHubの投稿を確認してください

データベースからユーザーのリストを照会して表示する具体的なワークフローは、次のように機能します。

何が違い間のMVCとMVPパターンは？

MVCパターン

• コントローラは動作に基づいており、ビュー間で共有できます

• 表示するビューを決定する責任があります（フロントコントローラーパターン）

MVPパターン

• ビューはモデルとより疎結合です。プレゼンターは、モデルをビューにバインドする責任があります。

• ビューとの対話はインターフェースを介して行われるため、単体テストが容易になります

• 通常、プレゼンターマップを1対1で表示します。複雑なビューには複数のプレゼンターがいる場合があります。

また、MVPにはさまざまなタイプがあることも覚えておいてください。Fowlerはパターンを2つに分割しました-パッシブビューと監視コントローラーです。

パッシブビューを使用する場合、ビューは通常、下層のUIウィジェットに大体直接プロパティをマッピングする、きめの細かいインターフェイスを実装します。たとえば、NameやAddressなどのプロパティを持つICustomerViewがあるとします。

実装は次のようになります。

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Presenterクラスはモデルに話しかけ、ビューに「マッピング」します。このアプローチは、「パッシブビュー」と呼ばれます。利点は、ビューのテストが容易であり、UIプラットフォーム（Web、Windows / XAMLなど）間を移動するのが簡単であることです。欠点は、データバインディング（WPFやSilverlightなどのフレームワークでは非常に強力です）などを利用できないことです。

MVPの2番目のフレーバーは、監視コントローラーです。その場合、ビューにはCustomerというプロパティがあり、このプロパティもUIウィジェットにデータバインドされます。ビューの同期やマイクロマネージメントについて考える必要はありません。監視コントローラーは、必要に応じて介入し、たとえば、対話ロジックをコンパイルすることで支援できます。

MVPの3番目の「フレーバー」（または、おそらく別のパターンと呼ぶ人）は、プレゼンテーションモデル（または、Model-View-ViewModelと呼ばれることもあります）です。MVPと比較すると、MとPを1つのクラスに「マージ」します。UIウィジェットがデータにバインドされている顧客オブジェクトがありますが、「IsButtonEnabled」や「IsReadOnly」などの追加のUI固有のフィールドもあります。

私がUIアーキテクチャで見つけた最高のリソースは、Jeremy MillerがThe Build Your Own CAB Seriesで行った一連のブログ投稿です。。彼はMVPのすべてのフレーバーをカバーし、それらを実装するためのC＃コードを示しました。

また、SilverlightのコンテキストでのModel-View-ViewModelパターンについて、YouCard Re-visited：Implementing the ViewModel patternでブログを書いています。

それぞれが異なる問題に対処し、組み合わせて以下のようなものにすることもできます

MVC、MVP、MVVMの完全な比較もここにあります

これらのフレームワークはどちらも、データソース（モデル）、アプリケーションロジック（またはこのデータを有用な情報に変換する）（コントローラー/プレゼンター）との相互作用、および表示コード（ビュー）などの懸念を分離することを目的としています。場合によっては、モデルを使用して、データソースをより高いレベルの抽象化に変えることもできます。この良い例がMVCストアフロントプロジェクトです。です。

ここで議論がありますMVCとMVPの違いについてます。

作成された違いは、MVCアプリケーションでは伝統的にビューとコントローラーがモデルと相互作用しますが、互いに相互作用しないことです。

MVP設計では、プレゼンターがモデルにアクセスし、ビューを操作します。

とは言っても、ASP.NET MVCはこれらの定義ではMVPフレームワークです。コントローラーがモデルにアクセスして、ロジックを持たない（コントローラーが提供する変数を表示する）ビューにデータを入力するためです。

ASP.NET MVCとMVPの違いを理解するには、スコットハンセルマンによるこのMIXプレゼンテーションをご覧ください。

どちらもプレゼンテーションとビジネスロジックを分離しようとするパターンであり、ビジネスロジックをUIの側面から切り離します

アーキテクチャ上、MVPはページコントローラベースのアプローチであり、MVCはフロントコントローラベースのアプローチです。つまり、MVP標準のWebフォームでは、ページのライフサイクルは、背後にあるコードからビジネスロジックを抽出することによって強化されるだけです。つまり、pageはhttpリクエストを処理する1つです。つまり、MVP IMHOはWebフォームの進化型の拡張機能です。一方、MVCでは、ページが読み込まれる前にリクエストがコントローラークラスによってインターセプトされ、そこでビジネスロジックがそこで実行され、コントローラーが処理した最終結果として、ページにダンプされたばかりのデータ（「ビュー」）が処理されるため、ゲームは完全に変わります。意味、MVCは（少なくとも私には）ルーティングエンジンで強化されたMVPの監視コントローラーフレーバーを多く見ます

どちらもTDDを有効にし、マイナス面とプラス面があります。

それらの1つを選択する方法の決定IMHOは、ASP NET WebフォームタイプのWeb開発に費やした時間に基づいて行う必要があります。自分がWebフォームに優れていると思うなら、MVPを勧めます。ページのライフサイクルなどに不快感を覚える場合は、MVCを使用してください。

これは、このトピックについてもう少し詳しく説明した別のブログ投稿リンクです

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

私はMVPとMVCの両方を使用しましたが、私たちは開発者として両方のパターンの技術的な違いに焦点を合わせる傾向がありますが、IMHOでのMVPのポイントは、何よりも採用の容易さに大きく関係しています。

私がすでにWebフォーム開発スタイルの優れた背景としてチームで働いている場合、MVCよりもMVPを導入する方がはるかに簡単です。このシナリオでのMVPはすぐに勝ちます。

私の経験では、チームをWebフォームからMVPに移動し、次にMVPからMVCに移動するのは比較的簡単です。WebフォームからMVCへの移行はより困難です。

私の友人がMVPとMVCについて公開した一連の記事へのリンクをここに残します。

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

MVPでは、ビューはモデルからデータを描画および準備/正規化するプレゼンターからデータを描画しますが、MVCでは、コントローラーはビューからプッシュすることでモデルおよび設定からデータを描画します。

MVPでは、1つのビューで複数のタイプのプレゼンターを操作し、1つのプレゼンターで複数の異なるビューを操作できます。

MVPは通常、Microsoft WPFバインディングフレームワークや、HTML5およびJava用のさまざまなバインディングフレームワークなど、ある種のバインディングフレームワークを使用します。

これらのフレームワークでは、UI / HTML5 / XAMLは各UI要素が表示するプレゼンターのプロパティを認識しているため、ビューをプレゼンターにバインドすると、ビューはプロパティを探し、それらからデータを描画する方法とその方法を知っています。ユーザーがUIで値を変更したときに設定します。

したがって、たとえば、モデルが自動車である場合、プレゼンターはある種の自動車のプレゼンターであり、自動車のプロパティ（年式、メーカー、座席など）をビューに公開します。ビューは、「car maker」というテキストフィールドにプレゼンターのMakerプロパティを表示する必要があることを認識しています。

次に、さまざまな種類のプレゼンターのビューにバインドできます。すべてにMakerプロパティが必要です。飛​​行機、電車など、ビューが気にしないものを使用できます。ビューは、合意されたインターフェースを実装している限り、プレゼンターからデータを描画します。

このバインディングフレームワーク、それを取り除くと、実際にはコントローラーになります:-)

したがって、MVPをMVCの進化形と見なすことができます。

MVCは素晴らしいですが、問題は通常、ビューごとのコントローラーです。コントローラAはビューAのフィールドを設定する方法を知っています。ここで、ビューAにモデルBのデータを表示させたい場合は、コントローラAがモデルBを知る必要があります。または、コントローラAがインターフェイスを持つオブジェクトを受け取る必要があります。バインディングなしのMVPのみ、またはコントローラーBのUIセットコードを書き換える必要があります。

結論-MVPとMVCはどちらもUIパターンの分離ですが、MVPは通常、MVCの下にあるバインディングフレームワークを使用します。THUS MVPは、MVCよりも高いアーキテクチャレベルで、MVCの上のラッパーパターンです。

私の控えめな短い見解：MVPは大規模用、MVCは小規模用です。MVCを使用すると、VとCが、Mに直接バインドされているのではなく、単一の分割できないコンポーネントの両側に表示される場合があると感じることがあります。このレベルの粒度では、MVPはほとんど意味がありません。逆に大規模になると、責任の明確な割り当てと同様に、適切なインターフェースがより重要になり、MVPが登場します。

一方、この経験則の目安は、プラットフォームの特性がコンポーネント間のある種の関係を好む場合、MVPよりもMVCを実装する方が簡単であると思われるWebなどの場合、ほとんど重み付けされないことがあります。

Erwin Vandervalk（および付随する記事）によるこの画像は、MVC、MVP、およびMVVM、それらの類似点、および相違点を最もよく説明していると思います。記事は、記事のタイトルは、言葉「MVC」と「MVP」が含まれていないため、「MVC、MVP、およびMVVM」のクエリの検索エンジンの検索結果には表示されません。でもそれが一番いい説明だと思います。

（この記事は、ボブマーティンおじさんが彼の講演の1つで言った内容にも一致します。MVCは元々、システムのアーキテクチャー用ではなく、小さなUIコンポーネント用に設計されたものです）

MVCには多くのバージョンがありますが、この答えはSmalltalkの元のMVCに関するものです。簡単に言えば、

このトークdroidcon NYC 2017-アーキテクチャコンポーネントを使用したクリーンなアプリデザインで明らかに

ボブおじさんからのこの素晴らしいビデオがあり、MVCとMVPについて簡単に説明しています。、最後しています。

IMO、MVPはMVCの改良版であり、基本的に、表示する内容（データ）の懸念と表示する方法（ビュー）を区別します。プレゼンターには、UIのビジネスロジックが含まれており、提示するデータを暗黙的に指定し、ダムビューモデルのリストを提供します。そして、データを表示するときが来たら、ビュー（おそらく同じIDを含む）をアダプターに接続し、最小限のコードが導入された（セッターを使用するだけで）これらのビューモデルを使用して関連するビューフィールドを設定します。その主な利点は、水平リストまたは垂直リストにアイテムを表示するなど、さまざまなビューに対してUIビジネスロジックをテストできることです。

MVCでは、インターフェイス（境界）を介して通信し、さまざまなレイヤーを接着します。コントローラは私たちのアーキテクチャのプラグインですが、何を表示するかを強制するような制限はありません。その意味で、MVPはMVCの一種であり、アダプターを介してコントローラーにプラグ可能なビューの概念があります。

私はこれがより良く役立つことを願っています。

Action-Domain-Responder（ADRについて忘れました）を。

上記のいくつかのグラフィックで説明したように、モデルとMVC のビューの間に直接的な関係/リンクがあります。アクションはコントローラーで実行され、コントローラーはモデルでアクションを実行します。モデルでのそのアクションは、ビューでの反応を引き起こします。ビューは、常にときに更新されたモデルの状態が変化します。

一部の人々は、MVC が70年代後半に作成されたことを忘れ続けていますこと、およびWebが80"後半/ 90 "初めにのみ作成されたます。MVCは元々Web用に作成されたのではなく、代わりにデスクトップアプリケーション用に作成されました。 、モデルとビューは共存します。

引き続き同じ命名規則（model-view-controller）を使用するWebフレームワーク（例：Laravel）を使用しているので、MVCである必要があると考えがちですが、実際には別のものです。

代わりに、Action-Domain-Responderをご覧ください。ADRでは、コントローラーはアクションを取得します。これは、モデル/ドメインで操作を実行します。これまでのところ、同じです。違いは、そのオペレーションの応答/データを収集し、それをレスポンダー（例：。view()）に渡してレンダリングすることです。同じコンポーネントで新しいアクションが要求されると、コントローラーが再度呼び出され、サイクルが繰り返されます。ADRでは、モデル/ドメインとビュー（Reponserの応答）の間に関係はありません。

注：ウィキペディアでは、「各ADRアクションは、個別のクラスまたはクロージャーによって表されます。」と述べています。これは必ずしも真実ではありません。複数のアクションを同じコントローラーに含めることができ、パターンは同じです。

MVC adr モデルビューコントローラー アクションドメインレスポンダ

最も簡単な答えは、ビューがモデルとどのように相互作用するかです。MVPでは、ビューはプレゼンターによって更新されます。プレゼンターは、ビューとモデルの間の仲介役として機能します。プレゼンターはビューから入力を受け取り、モデルからデータを取得して、必要なビジネスロジックを実行し、ビューを更新します。MVCでは、モデルはコントローラーを経由するのではなく、ビューを直接更新します。

• MVCでは、ビューにUIパーツがあり、コントローラーはビューとモデル間の仲介者であり、モデルにはビジネスロジックが含まれます。
• MVPでは、ビューにはプレゼンターのUIと実装の両方が含まれます。プレゼンターは単なるインターフェースであり、モデルは同じである、つまりビジネスロジックが含まれているためです。

MVP

MVPは、Model-View- Presenterの略です。これは、2007年の初めにMicrosoftがスマートクライアントWindowsアプリケーションを導入したときのことです。

プレゼンターは、モデルからのビューイベントとビジネスロジックをバインドするMVPの監督上の役割を果たしています。

ビューイベントバインディングは、ビューインターフェイスからPresenterに実装されます。

ビューはユーザー入力のイニシエーターであり、イベントをプレゼンターに委任し、プレゼンターはイベントバインディングを処理してモデルからデータを取得します。

長所： ビューにはUIのみがあり、ロジックはありません。

短所： イベントバインディングを実装するときに少し複雑で作業が増える

MVC

MVCはModel-View-Controllerの略です。コントローラは、モデルの作成とバインディングモデルを使用したビューのレンダリングを担当します。

コントローラーはイニシエーターであり、レンダリングするビューを決定します。

長所： 単一の責任原則の強調高いテスト容易性

短所： 同じコントローラーで複数のビューをレンダリングしようとすると、コントローラーのワークロードが多すぎる場合があります。