MVPVM パターン
最近俄かに出てきたのが、この MVPVM というパターン。MVVM をより発展させたパターンらしいです。図にするとざっとこんな感じらしい。
現状日本語で詳しく解説してるのは、MSDN マガジンの記事だけ。もっとも原文は英語なので、若干翻訳が怪しいとこあるけど。
WPF 向けのモデル - ビュー - プレゼンター - ビューモデル設計パターン
某所のやりとり*1を見ると、ある御仁が MVPVM のプレゼンターについて 「Presenter = コードビハインド」 なんて解釈してるけどそうじゃないよね。上記ドキュメント内のビューの項では
MVPVM では、分離コードにコードを記述する必要はまったくありません
とはっきり述べてます。
また面白いなと思ったのがビューモデルについて。ドキュメントではこんなこと言ってます。
MVPVM: ビューモデル
「MVP では、モデルは純粋なドメイン オブジェクトで、ユーザー インターフェイスに関する想定 (リンク) はありません。」(「3 要素の仕掛け」より)この定義のため、ビューモデルは 1 つのビューに密結合されず、多数のビューから再利用できます。同様に、ビューモデルはアプリケーション ビジネス ロジックを含まないため、複数のエンタープライズ アプリケーションからビューモデルを簡単に共有できます。そのため、再利用とアプリケーションの統合が進みます。たとえば、図 8 の右下の 28 行目をご覧ください。この SecurityCommandViewModel は、Gwn.Library.MvpVm.xxxx プロジェクト (xxxx は Silverlight、Desktop、または Phone) に含まれています。"ユーザー" ビューモデルはほとんどのアプリケーションで必要になるので、このビューモデルは再利用可能なコンポーネントです。デモ アプリケーション固有のビジネス ロジックをこのビューモデルに含めないよう、注意する必要があります。この作業は、MVPVM では難しくはありません。なぜなら、ビューモデル内ではなく、プレゼンターでビジネス ロジックを処理するためです。
(注: ビューモデルのプロパティをプレゼンターから設定すると、NotifyPropertyChanged イベントが発生し、新しいデータが存在することがビューに通知されます。通知後にビューモデルのデータに合わせてビューを更新するのは、ビュー自体の役割です。)
なるほどね・・・ビューモデルをビューと 1 対 1 の関係にせず、複数のビューから利用可能なように共通ライブラリに置いておくと言ってます。これもプレゼンターに処理を委譲しないとできない話ですよね。
この辺りのことについては、明日の RIA 研究会でえムナウさんが色々語ってくださると思いますので、ぜひじっくり聴いてみたいと思います。
