C#と諸々

MVP パターンについて、僕なりに理解していること、こうした方が良いと思うことを書き綴ってみようと思います。
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

• Model は、Presenter に依存しません。

[View]
View は、Presenter の要求インターフェイスを実装し、ユーザーインターフェイスを直接操作します。
View は、極力無能にします。そのためには、UI コントロールとの直接的なやり取り以外をできるだけ行わないようにします。

View → Presenter

• View は、Presenter に自分自身を関連付けます。
• View は、ユーザーからの入力イベントを受け取り、処理を Presenter に委譲します。
• View は、上記以外の目的で Presenter を操作しません。

View → Model

• View は、Presenter から Model を受け取って出力することができます。
• View は、Model を生成しません。
• View は、出力に必要な操作以外で、Model を操作しません。

[Presenter]
Presenter は、View を通じて、ユーザーからの入力イベントを受け取ります。その後、Model を操作したり View を操作したりします。

Presenter → View

• Presenter は、View から入力値を取得することができます。
• Presenter は、View を操作することができます。

Presenter → Model

• Presenter は、Model を生成したり操作することができます。

Presenter → その他

• Presenter は、Model や View に属さないもの (データストアやハードウェア等) に関する処理を行うことができます。

[View と Presenter の関係]
前述の通り、View は、Presenter の要求インターフェイスを実装します。この要求インターフェイスは、View が極力無能になるように考慮して定義します。
Presenter と View は１対１の関係で、一つの Presenter を複数の View に関連付けることは通常しません。


[Model の変更通知について]
MVP パターンも MVC パターンと同じく、Model が View に変更を通知することができます。ただし、これは必須ではなく、この記事でもこれを含めていません。(つか、そっちはよく知りません。)
こちらの記事によると、このように Model の変更通知を無くして Presenter が完全に View 操作を行うことを、「慎ましいビュー (Humble View)」 と呼ぶそうです。



つづく