StackOverFlowの「MVPとMVCの違い」についての回答を読んでみた

MVPとMVCとかMVVMとかの違いについて自分は、あんまりちゃんと分かっていませんでした。

StackOverFlowの「What are MVP and MVC and what is the difference?」という質問の回答が2015/09/23現在、1213人がUsefulにしていて、他の場所でも紹介されていて、読んでみようと思いました。
自信がない場所が多いので、勘違いや間違っている箇所が多々あると思いますので、優しくご指摘をお願いします。。

自分は読んでみて、なんとなく違いがわかったのと、またMVPとPresentation Model(Model-View-ViewModel)の違いについても出てくるので勉強になりました。

What are MVP and MVC and what is the difference?
http://stackoverflow.com/a/101561

Model-View-Presenter

PresenterにはViewのためのUIのビジネスロジックを書く

• PresenterはViewをデリゲートしてイベントを受け取る
• PresenterはViewから分離されている。Viewをinterfaceを通して操作する
  • なのでViewをモックとしてテストしやすい

Presenterの特徴

• View→PresenterとPresenter→Viewをたくさん持っている。
  • 例 : "Save"Buttonクリック→ViewのイベントハンドラはPresenterにデリゲートされているので、Presenterで"OnSave"が呼び出される→セーブが終わったら、PresenterからInterfaceを通してViewにセーブされたよって表示する。

2つのMVPのバリエーション

MVPには２つのバリエーションが有ります。

Passive View

Viewの中のロジックはなるべくなくして、PresenterをViewとModelを仲介させるようにして、Modelがデータに変更があったなどのイベントを発行して、Presenterがそれを受けて、PresenterがViewをアップデートします。完全にModelとViewが分離されています。
Viewには様々なセッターが存在して、View自体では状態を管理せず、Presenterが状態を管理します。

良い点 ViewとModelが綺麗に分かれていてとてもテストがしやすい。
悪い点 たくさんセッターを書かなくてはいけないなど大変です。

イメージ

Supervising Controller

データバインディングという仕組みを利用してModelからViewへのバインドする方法です。この場合Presenterで行っていたModelからViewへデータを渡すためのコードが必要なくなります。Presenterにはボタンをおした時のロジックやどこに移動するかのロジックなどが書かれていることになります。

良い点: データバインディングの力によりコードが減らせること
悪い点: データバインディングによりテストのしやすさが減ってしまう。ModelとViewが直接つながるのでカプセル化がうまく行えていない。

Model-View-Controller

MVCにおいてControllerは全てのアクションに対して応答するViewを決定する責任があります。
このMVCのMVPとの違いは二点あります。

• ViewからPresenter(Controller)への呼び出しの流れが違う
  MVCではViewの中のアクションがControllerを呼び出す関係となります。
  例えば、Webにおいて、Viewの中のアクションはURLの呼び出し、それに応答するControllerが処理を行います。そして、コントローラーが処理が終わると、正しいViewを返します。 以下の様な流れとなります。

    Viewの中のアクション
        -> Controllerの呼び出し
        -> Controllerのロジック
        -> Viewを返す

• ViewがModelに(直接)つながらない
  MVCではViewはシンプルに表示のみです。そして完全に状態を持ちません。Viewに対してのみのロジックがない、すなわちMVCの実装は、MVPだと絶対に必要なViewからPresenterへのデリゲートが無い点です。

イメージ

Presentation Model(Model-View-ViewModel)

もう一つの見ておくべきパターンとしてPresentation Modelパターンが有ります。このパターンにおいてPresenterは存在しません。その代わりViewはPresentation Modelと直接バインドします。

Presentation Modelは表示するViewのために作られています。これによりModelとViewが直接つがらないので、MVPのSupervising Controllerの問題点のカプセル化の問題も解消することができます。

この場合、Presentation ModelはModelからのイベントを購読しています。ViewはPresentation Modelから来たイベントを購読して、それを受けて更新を行います。

Presentation Modelは幾つかのコマンドを公開することができます。そのコマンドはViewのアクションを呼び出すためのものです。このアプローチのいいところはPresentation ModelがViewの振る舞いを完全にカプセル化して、コードビハインドを削除できるということです。またModel-View-ViewModelパターンとも呼ばれます。

イメージ