MVCまたはMVPですか？どのデザインパターンが最も理にかなっていますか？

Question

あなたはどちらを好きですか？私は両方を調べてきましたが、人々がそれらを呼んでいることに間違いがあるようです。

私は、違いが何であるかを書き留めておき、私が間違っていれば私を修正できます。

MVC

1. モデルは、それがオブザーバーに通知モデルへの更新に、それ自身のオブザーバー（ビュー）への参照を保持しています。
2. ビューは、すべてのイベントとメッセージをコントローラに渡します。ビューは、モデルによって変更が発生したことが通知されると、その内容を更新します。ビューには、コントローラとモデルへの参照が保持されます。
3. コントローラはモデルを保持し、（時には）ビューを保持します。ユーザ入力に対応するコントローラメソッドを呼び出すビュー、コントローラは、次によう応じモデルmaniuplates、時には（特定のビューをクリック上のボタンをブロッキング、等）を表示

MVPを操作

1. モデルにはビューへの参照がありません。プログラムのデータ抽象化のみを提供します。モデルには何も参照されません。
2. MVCビューと同様に、ユーザーの入力に応じて対応するPresenterメソッドを呼び出します。ビューにはプレゼンターのみが参照できます。
3. Presenterにはビューとモデルの参照があります。ビューがプレゼンターのメソッドを呼び出すと、プレゼンターはモデルを操作してからビューを操作します。

私はMVCの仕組みを理解していますが、MVPがiffyのようなものであれば分かります。私は本当にMVCが本当に気に入っていますが、私にはあまりうまくいかない部分は、データレイヤーの抽象化だけになっているモデルもViewsへの参照を保持して更新するという事実です。それは意味をなさない。

Answer 1

Martin Fowler氏は、MVCとMVPのanalysisを提供し、ウィキペディアMVP記事は、より多くの参照を提供します。

私にとって、2つの質問があります：

1）。モデルビューの関係は「生きて」いるのですか？モデルが動的に変更され、そのモデルの変更を反映するためにビューを更新する必要がある場合、従来のMVCがあり、モデルは何らかの形で関連するビューを通知します。このスタイルは、従来のWebアプリケーション（Strutsで実装されているものなど）には適用されません。ここには、モデルのスナップショットの1つとして作成されたビュー（実際には、モデルによって提供されるDTO上にあることが多い）があります。多くの文献では、Webスタイルは依然としてMVCと呼ばれています。

2）。ユーザーが「何か」をしたとき、誰が解釈と行動を担当するのか。 MVCでは、これは通常、Controllersジョブです。 MVPは、この目的のためにViewからModelへのより直接的なやりとりを可能にしているようです（私がFowlersの記事を正しく理解していれば）。

私は心配のきれいな分離を好む - MVCのアプローチは私の考え方ですが、それはちょうど親しみのものかもしれません。

人は何を選ぶべきですか？一般に、私はあなたが使用するフレームワークに頼っていると思います。私はStrutsのバックグラウンドから来ているので、WebスタイルのMVCは私にとって自然です。私が正しく理解していれば、MVPは.NETのいくつかの側面で明示的に採用されています。 MVPではなく、MVPであるという理由だけでフレームワークを拒否することはありません。たとえ明確な区別ができていたとしても、私はフレームワークを拒否しません。

Answer 2

私の理解が正しいと仮定して、モデルはMVPまたはMVCのビューへの参照を保持すべきではありません。

MVC/MVPの実装方法の定義は、次の人たちとは多少異なる場合があります。私はパターンが懸念の分離の一般的なアイデアのためにそこにあると思うが、特定の実装に必要なものに正確に合うように適合させることができる。

Answer 3

私はそれがあなたがいる環境に依存すると思います。ウェブ環境では、コントローラはリクエストの結果、どのビューを表示するかを選択します。その前に、コントローラーはモデルに変更があるかどうかをチェックします。言い換えれば、ビューはモデルとの直接的な関係を必要としません。

Answer 4

MVVMについてはどうですか？ （モデルビュービューモデル）このスタイルでは、モデルはビューへの参照を保持しません。また、その逆もあります。私はそれを学ぶことを始めたばかりなので、多くを知っているようなふりをすることはありませんが、最近、このデザインパターンに移行する選択をしました。したがって、私はそれにいくつかメリットがあると仮定しています。

http://en.wikipedia.org/wiki/Model_View_ViewModel

Answer 5

どちらのパターンでも、モデルは他のコンポーネントに依存することはできません。 Observerオブジェクトに対してのみ「参照あり」があります。それらのオブザーバーがビュー、コントローラーまたは他のモデルであるかどうかは気にしません。

MVCは最も誤って引用されたデザインパターンであり、実際の定義に欠けています。 Martin Fowlerが発行したものを使用します。

デスクトップアプリケーションの複雑なビジネスオブジェクトのUI/CRUD画面について考えてみましょう。 （MVCのようなStrutsは少し異なります）。 1つのモデル（ビジネスオブジェクト）、複数のビューが画面上にあり、各ビューにはそれぞれ独自のコントローラがあります。

ビューロジックとコントローラオブジェクト全体に、UIロジック（ビジネスオブジェクトに関するウィジェットの検証、有効化）が散在しています。この意味でMVCパターンは時代遅れですが（！）、当時の関心事の分離は画期的であり、豊かなUIを可能にしました。

MVPには、モデルがあります。ビューはダムで、すべてのUIロジックはPresenter内にあります。プレゼンターは、View要素にアクション/イベントハンドラー/代理人を提供します。そのため、ユーザーが画面上の対応するウィジェットとやりとりすると、「表示」は単にプレゼンターにコールバックします。プレゼンターはメディエータとして機能し、ウィジェットの相互作用をカプセル化します。

私はこのリンクを本当にお勧めしますhttp://martinfowler.com/eaaDev/uiArchs.html。 MVCの話題全体が聞こえるほど簡単ではありません。それは、ほとんどそれ自身の理論です。