user-interface - MVPとMVCとは何ですか？違いは何ですか？

Question

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

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

score 2082 · Accepted Answer

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

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

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

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

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

Pro：最大の妥当性の表面。ビューとモデルのクリーンな分離
短所：すべてのデータバインディングを自分で行うため、より多くの作業（たとえば、すべてのセッタープロパティ）が行われます。

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

長所：データバインディングを活用することで、コードの量が削減されます。
短所:(データバインディングのために）テスト可能なサーフェスが少なく、モデルと直接通信するため、ビューでのカプセル化が少なくなります。

Model-View-Controller

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

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

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

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

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

プレゼンテーションモデルに関するMSDNの記事と、分離されたプレゼンテーションパターンに関する WPF（旧Prism）の複合アプリケーションガイダンスのセクションがあります。

score 438 · Accepted Answer

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

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

MVPパターン

ビューはモデルとより緩く結合されています。プレゼンターは、モデルをビューにバインドする責任があります。

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

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

MVCパターン

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

表示するビューを決定する責任があります

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

score 275 · Accepted Answer

275

コミュニケーションの流れをイラストで表現

ここに画像の説明を入力

于 2014-09-12T20:47:56.560 に答える

score 181 · Accepted Answer

MVP は、必ずしもビューが担当するシナリオではありません(例として、Taligent の MVP を参照してください)。
「それはただの見解だ」（プラグマティックプログラマー）と矛盾するため、人々がまだこれをアンチパターンではなくパターン（担当ビュー）として説いていることは残念です。「単なるビューです」とは、ユーザーに表示される最終的なビューは、アプリケーションの二次的な関心事であると述べています。Microsoft の MVP パターンは、View の再利用をはるかに困難にし、Microsoft の設計者が悪い慣行を助長するのを好都合に言い訳します。

率直に言うと、MVC の根底にある懸念は、どの MVP 実装にも当てはまり、その違いはほぼ完全に意味論的なものだと思います。ビュー (データを表示する)、コントローラー (ユーザーの操作を初期化および制御する)、およびモデル (基礎となるデータおよび/またはサービス) の間の関心の分離に従っている限り、MVC の利点を実現できます。 . 利点を達成している場合、パターンが MVC、MVP、または監視コントローラーであるかどうかを誰が本当に気にしますか? 唯一の実際のパターンは MVC のままで、残りはそのフレーバーが異なるだけです。

これらのさまざまな実装の多くを包括的にリストしているこの非常にエキサイティングな記事を検討してください。それらはすべて基本的に同じことをしているが、わずかに異なっていることに気付くかもしれません。

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

score 120 · Accepted Answer

MVP: ビューが担当します。

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

MVC: コントローラーが担当します。

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

score 82 · Accepted Answer

MVC (モデルビューコントローラー)

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

MVP (モデルビュープレゼンター)

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

詳細については

score 37 · Accepted Answer

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

score 35 · Accepted Answer

また、覚えておく価値があるのは、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 番目のフレーバーは、監視コントローラーです。その場合、View には Customer というプロパティがあり、UI ウィジェットに再びデータバインドされます。ビューの同期や詳細な管理について考える必要はありません。また、Supervising Controller が介入して、必要に応じて支援することができます (たとえば、完全な対話ロジックを使用)。

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

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

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

score 21 · Accepted Answer

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

ここでは、MVCとMVPの違いについて説明しています。

区別されるのは、MVCアプリケーションでは、従来、ビューとコントローラーがモデルと相互作用するが、相互には相互作用しないということです。

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

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

ASP.NET MVCとMVPの違いを理解するには、 ScottHanselmanによるこのMIXプレゼンテーションを確認してください。

score 14 · Accepted Answer

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

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

どちらも TDD を有効にし、欠点と利点があります。

それらのいずれかを選択する方法についての決定 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

score 10 · Accepted Answer

私は 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

score 7 · Accepted Answer

私の謙虚な短い見解: MVP は大きなスケール用であり、MVC は小さなスケール用です。MVC では、V と C が、M に直接バインドされているのではなく、1 つの分割できないコンポーネントの 2 つの側面として見られる場合があると感じることがあります。UI コントロールやベースウィジェットのように、より短いスケールに移行すると、一方が必然的にこれに該当します。このレベルの粒度では、MVP はほとんど意味がありません。逆にスケールが大きくなると、明確な責任の割り当てと同様に、適切なインターフェースがより重要になり、MVP が登場します。

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

score 6 · Accepted Answer

MVC には多くのバージョンがあります。この回答は、Smalltalk の元の MVC に関するものです。要するに、それは

このトークdroidcon NYC 2017 - アーキテクチャコンポーネントを使用したクリーンなアプリデザインはそれを明確にします

score -1 · Accepted Answer

MVP

MVP は、モデル - ビュー - プレゼンターの略です。これは、Microsoft が Smart Client Windows アプリケーションを導入した 2007 年初頭に明らかになりました。

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

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

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

長所: ビューには UI のみがあり、ロジックはありません高レベルのテスト容易性

短所: イベントバインディングを実装する場合、少し複雑で作業が多くなります。

MVC

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

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

長所: 単一責任原則の強調高レベルのテスト可能性

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