MVP パターンは書籍「ドメイン駆動」で知りましたが、GUI Architectures は英文苦手なので読んでません。だから、違うこと言っている可能性もあります。どちらかというと、僕が MVP パターンを適用する時の個人的な考え方、ということになるかもしれません。
また、ここでは特に、ASP.NET 開発で MVP パターンを適用する場合について書いていきます。もしかしたら、それ以外の開発では若干当てはまらない点があるかもしれません。
[MVP パターンとは]
MVP (Model View Presenter) パターンは、MVC (Model View Controller) パターンの亜種です。
大きな違いとして、MVC パターンでは Controller がユーザーからの入力イベントを受け取りますが、MVP パターンでは View がユーザーからの入力イベントを受け取り、処理を Presenter に委譲します。
[Model]
Model は、ドメインモデルを表します。
ドメインとは、業務固有の問題領域のことです。
Model → View
- Model は、View に依存しません。
- Model は、Presenter に依存しません。
[View]
View は、Presenter の要求インターフェイスを実装し、ユーザーインターフェイスを直接操作します。
View は、極力無能にします。そのためには、UI コントロールとの直接的なやり取り以外をできるだけ行わないようにします。
View → Presenter
- View は、Presenter に自分自身を関連付けます。
- View は、ユーザーからの入力イベントを受け取り、処理を Presenter に委譲します。
- View は、上記以外の目的で Presenter を操作しません。
- View は、Presenter から Model を受け取って出力することができます。
- View は、Model を生成しません。
- View は、出力に必要な操作以外で、Model を操作しません。
[Presenter]
Presenter は、View を通じて、ユーザーからの入力イベントを受け取ります。その後、Model を操作したり View を操作したりします。
Presenter → View
- Presenter は、View から入力値を取得することができます。
- Presenter は、View を操作することができます。
- Presenter は、Model を生成したり操作することができます。
- Presenter は、Model や View に属さないもの (データストアやハードウェア等) に関する処理を行うことができます。
[View と Presenter の関係]
前述の通り、View は、Presenter の要求インターフェイスを実装します。この要求インターフェイスは、View が極力無能になるように考慮して定義します。
Presenter と View は1対1の関係で、一つの Presenter を複数の View に関連付けることは通常しません。
[Model の変更通知について]
MVP パターンも MVC パターンと同じく、Model が View に変更を通知することができます。ただし、これは必須ではなく、この記事でもこれを含めていません。(つか、そっちはよく知りません。)
こちらの記事によると、このように Model の変更通知を無くして Presenter が完全に View 操作を行うことを、「慎ましいビュー (Humble View)」 と呼ぶそうです。
つづく