57

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

プレゼンター、プレゼンテーションモデル、ViewModel、コントローラーは基本的に同じ概念のようです。

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

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

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

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

4

6 に答える 6

69

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

MVCのコントローラー：

  • コントローラは、ユーザーの操作の結果として呼び出される実際のコンポーネントです。（開発者は、呼び出しをコントローラーに委任するためのコードを記述する必要はありません。）

  • コントローラは、ビュー/コンテキスト/バッグ/何からでも現在の値を取得しますが、ビューと相互作用するとは言えません。

  • コントローラは、最終的にどのビューをユーザーに表示するかを決定します。その中で、Controllerはアプリケーションナビゲーションワークフローの明示的な概念も示しています。

MVPのプレゼンター：

  • プレゼンターには、ビューによって呼び出されるメソッドがあります。これは、ユーザーの操作時に制御を受け取る実際のコンポーネントです。（開発者は、プレゼンターを呼び出すために、ビューにコードを記述する必要があります。）

  • プレゼンターは、ビューから何らかの方法で現在の値を取得するか、呼び出し時にビューからそれらを受け取ります。Presenterは、ビューの状態を設定するためにビューのメソッドを呼び出します（Josh Smithと表示されます）。プレゼンターによって呼び出されるViewメソッドでは、本体でいくつかの小さな設定が実行される場合があります。

  • プレゼンターは、アプリケーションワークフローの概念を明示的に示していません。これは通常、呼び出し元のビューに制御を戻すと考えられています。

PMのPresentationModel：

  • PresentationModelには、ビューによって呼び出されるメソッドがあります。これは、ユーザーの操作時に制御を受け取る実際のコンポーネントです。（開発者は、PresentationModelを呼び出すために、ビューにコードを記述する必要があります。）

  • PresentationModelは、プレゼンターと比較して、Viewとのコミュニケーションがはるかに面白くなります。また、ビューに適用するすべての設定の値を把握し、実際にビューに設定するためのロジックも含まれています。（これらのViewメソッドには、ほとんどロジックがありません。）

  • PresentationModelは、アプリケーションワークフローの概念を明示的に示していません。これは通常、呼び出し元のビューに制御を戻すと考えられています。

MVVMのViewModel：

  • ViewModelには、ビューによって呼び出される（＆プロパティセット）メソッドがあります。これは、ユーザーの操作時に制御を受け取る実際のコンポーネントです。（開発者は、ViewModelを呼び出すために、ビューにいくつかの（宣言型）コードを記述する必要があります。）

  • ViewModelは、PresentationModelと比較してViewと明示的におしゃべりな通信を行いません（つまり、Viewをあまり呼び出さず、フレームワークが呼び出します）。ただし、ビュー設定で1対1にマップする多くのプロパティがあります。これらすべての設定の値を把握するための同じロジックがまだ含まれています。

  • ViewModelは、アプリケーションワークフローの概念を明示的に示していません。これは通常、呼び出し元のビューに制御を戻すと考えられています。

  • Josh Smithの言うことをなんとかしてコピーする（http://msdn.microsoft.com/en-us/magazine/dd419663.aspx）：MVVMパターンは、フレームワーク（WPF / SLなど）を順番に利用するPMの特殊なケースです。より少ないコードを書くために。

于 2011-02-26T00:48:47.307 に答える
47

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

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

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

一方、プレゼンターはより受動的であり、独自のイベントなどを処理するUIを介してデータを表示するか、プレゼンターを介してサービスまたはコマンドにデータを委任します。

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

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

于 2011-01-06T05:01:09.660 に答える
6

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

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

編集：

もう1つの記事-比較。

于 2011-01-02T23:28:47.290 に答える
6

私の意見では、MVP、MVVC、MVC、およびプレゼンテーションモデルの間に実際の概念上の違いはありません。いくつかの詳細な違いがありますが、最終的には、すべてモデルビューコントローラーのセットアップと見なすことができます。余分な名前は混乱を招くだけなので、コントローラーを説明する際にある程度の自由度を考慮した用語を採用する方がよいと思います。

于 2011-01-06T03:34:27.150 に答える
1

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

于 2011-01-02T23:12:06.917 に答える
1

MVPとMVVMの重要な違いの1つは、VMを多くのビューで使用できることです。MVPは通常、プレゼンターとビューの間で1対1であり、そのメソッドを適用するコントラクトインターフェイスを備えています。Androidは、保持されたフラグメントの上に構築されたViewModelコンポーネントにMVVMを組み込むために多くのことを行いました。これはアーキテクチャに最適なパターンであり、あらゆるアプリに適しています。

于 2018-12-09T21:44:50.973 に答える