Presenter、Presentation Model、ViewModel、Controllerの違いは何ですか？

Question

私はこれらのパターンのそれぞれがどのように機能するかについてかなり良い考えを持っています、そしてそれらの間の小さな違いのいくつかについて知っていますが、それらは本当にお互いにそれほど違うのですか？

Presenter、Presentation Model、ViewModel、およびControllerは基本的に同じ概念であるように思えます。

これらの概念をすべてコントローラーとして分類できないのはなぜですか？アイデア全体を大幅に簡略化できると思います。

誰かが違いを明確に説明できますか？

私はパターンがどのように機能するかを理解しており、それらのほとんどを1つのテクノロジーまたは別のテクノロジーに実装したことを明確にしたいと思います。私が本当に探しているのは、これらのパターンの1つを使用した経験と、たとえばViewModelをコントローラーと見なさない理由です。

私はこれについていくつかの評判ポイントをあげますが、私は本当に良い答えを探しています。

superjos · Accepted Answer

既に述べた素晴らしい読み物（Fowler＆Miller）に加えて、コントローラー/プレゼンター/ ...の違いに関するあなたの意見に、開発者の観点から返信します：

MVCのコントローラー：

コントローラーは、ユーザーとの対話の結果として呼び出される実際のコンポーネントです。（開発者は、コントローラーへの呼び出しを委任するコードを記述する必要はありません。）
コントローラーはなんとかしてビュー/コンテキスト/バッグ/何からでも現在の値を取得しますが、それがビューと相互作用しているとは実際には言わないでしょう。
最終的に、コントローラーはユーザーに表示するビューを決定します。その中で、コントローラーはアプリケーションナビゲーションワークフローの明示的な概念も示しています。

MVPでのプレゼンター：

Presenterには、ビューによって呼び出されるメソッドがあります。これは、ユーザーの操作時にコントロールを受け取る実際のコンポーネントです。（開発者は、プレゼンターを呼び出すためにビューにコードを記述する必要があります。）
Presenterは、ビューから何らかの方法で現在の値を取得するか、呼び出し時にビューからそれらの値を受け取ります。プレゼンターはビューのメソッドを呼び出して、その状態を設定します（populate itはJosh Smithと言います）。プレゼンターによって呼び出されたViewメソッドmightのボディでは、いくつかの小さな設定が実行されます。
Presenterは、アプリケーションワークフローの概念を明示的に示していません。通常、コントロールを呼び出し元のビューに戻すと考えられます。

PMのプレゼンテーションモデル：

PresentationModelには、Viewによって呼び出されるメソッドがあります。Viewは、ユーザーの操作時にコントロールを受け取る実際のコンポーネントです。（開発者は、PresentationModelを呼び出すためにビューにコードを記述する必要があります。）
PresentationModelは、Presenterと比較して、Viewとのchatty通信がはるかに多くなります。また、ビューに適用するすべての設定の値を把握し、実際にビューに設定するためのロジックも含まれています。（これらのViewメソッドには、ほとんどロジックがありません。）
PresentationModelは、アプリケーションワークフローの概念を明示的に示しません。通常、コントロールを呼び出し元のビューに戻すと考えられます。

MVVMのViewModel：

ViewModelには、ビューによって呼び出される（＆プロパティセット）メソッドがあります。これは、ユーザーとの対話時にコントロールを受け取る実際のコンポーネントです。（開発者は、ViewModelを呼び出すために、ビューに（宣言的な）コードを記述する必要があります。）
ViewModelは、PresentationModelと比較して、Viewと明示的にチャットを行いません（つまり、Viewを頻繁に呼び出さず、フレームワークが呼び出します）。ただし、ビュー設定で1対1にマップする多くのプロパティがあります。これらの設定の値を計算するための同じロジックがまだ含まれています。
ViewModelは、アプリケーションワークフローの概念を明示的に示していません。通常、コントロールを呼び出し元のビューに戻すと考えられます。
ジョシュ・スミスの発言を何らかの形でコピーする（ http://msdn.Microsoft.com/en-us/magazine/dd419663.aspx ）：MVVMパターンはPMの特殊なケースですより少ないコードを書くために（WPF/SLのような）フレームワークを利用します。

Cameron MacFarland · Answer

Martin Fowlerは、UIデザインパターンに関するページを公開しています。このページでは、MVC、MVP、およびその他のパターンを定義して説明しています。

http://martinfowler.com/eaaDev/uiArchs.html

Controllerは、UIの制御でアクティブです。たとえば、UIによってトリガーされたイベントを処理し、適切に処理します。

一方、Presenterはよりパッシブであり、UIを介してデータを表示し、それ自体のイベントなどを処理するか、プレゼンターを介してデータを委任しますサービスまたはコマンド。

ViewModelは、WPF/Silverlightバインディングで使用するために設計されたプレゼンターの特定の例です。

プレゼンテーションモデルは、ビューによって直接提示できるモデルであるため、たとえば、モデルがデータバインディング用にINotifyPropertyChangedを実装している場合、それらはプレゼンテーションモデルになります。。

too · Answer

それらの違いは基本的に、ビューに含まれるコードの量にあります。それらの間の選択は、実際にはWFP、WinForms、ASP MVC（2）などのアプリケーションのテクノロジの選択です。）ロジックをプレゼンテーションから分離する基本的な考え方は同じです。

ここは3つすべてについて非常に良い記事です。

編集：

One その他の記事-比較。

ここは3つすべてについて非常に良い記事です。

編集：

One その他の記事-比較。

Nicholas · Answer

私の意見では、MVP、MVVC、MVC、およびプレゼンテーションモデルの間に実際の概念的な違いはありません。いくつかの詳細な違いがありますが、結局のところ、すべてを引き続きモデルビューコントローラーのセットアップと見なすことができます。追加の命名は混乱を招くだけの役割を果たすので、コントローラーを説明する際にある程度の寛容さを可能にする用語を採用する方が良いと思います。

Stefan H · Answer

少なくとも.Netでは、MVPが設計パターンとして使用されています。これは通常、Windowsフォームアプリケーションまたは従来のASP.Netで使用されます。 MVCおよびMVVCでは、これらは通常、ASP MVCで使用されます。これは、通常のASP.Netとはかなり異なるアーキテクチャを使用します。