トロこんぶ

なぜ今Apache Camelを学ぶ必要があるのか？

2018-06-08T15:47:00.001+09:00

なぜ今 Apache Camel を学ぶ必要があるのか?

- なぜ今Apache Camelを学ぶ必要があるのか？ -
https://jcug-oss.github.io/article/why-do-we-have-to-learn-camel-q

現在、私はRed Hat社にて Red Hat FuseとRed Hat AMQという製品のサポートをしているのですが、Red Hat Fuse のコアコンポーネントは Apache Camelになっています。

このApache Camelは既に10年以上の歴史を持つのですが、なぜ今Apache Camelを学ぶ必要があるのか、大まかな機能とアーキテクチャから説明した記事を書きました。読むのに多分10分くらいかかるのですが興味ある方はご覧ください。

また、月１回のペースでCamel In Action 読書会を行っていますので、興味ある方はご参加ください。

- Japan Camel User Group
https://jcug-oss.connpass.com

Redshift設計での個人的知見のまとめ　その３

2016-12-11T23:55:00.001+09:00

データ収集とデータマート構築プログラム

ここでは、データの源泉となるシステムからデータ収集を行い、Redshiftへとデータを配置してデータマートを構築を行う制御プログラムについて説明する。

制御プログラムの実行内容：

①．データの源泉となるシステムからデータを取得し、CSVにしてS3に配置する
②．S3のCSVデータをRedshiftのステージングレイヤにロードする
③．ステージングレイヤのデータをオリジナルレイヤにアップサートする
④．オリジナルレイヤの有効期限を迎えたデータを除いてディープコピーを行う
⑤．モデルレイヤのテーブルを導出する
⑥．データマートレイヤのテーブルを導出する

これらの実行内容をEC2インスタンスを深夜に定期的に起動して実行させていた。

①．データの源泉となるシステムからデータを取得し、CSVにしてS3に配置する

データの源泉となるのは主にデータベースだろう、データベース以外だとログファイルなどだろうか。RedshiftはS3上のCSVやJSONなどからデータロードすることができるが、私の場合には、データベースの内容をJDBCを通し、作成日時と更新日時を確認して必要な差分データを取得できるSQLを発行し、10000件ごとのGZIP圧縮されたCSVにフォーマット変換してローカルファイル出力しつつ、それを順次S3にアップした。

10000件ごとにCSVファイルにするのはいくつか理由がある。まずデータをすべて取得する前にS3への転送を始められるために転送完了までの時間を短縮できること。それから制御プログラムのEC2インスタンスに滞留するデータが少なくなるために必要とされるメモリやディスク容量を少なく保てること。そして、Redshiftは複数のCSVファイルを指定してCopyすると並列ロードが行われてロード時間を短縮することができるからだ。

②．S3のCSVデータをRedshiftのステージングレイヤにロードする

S3のCSVデータをRedshiftのステージングレイヤにロードするにはcopyコマンドを利用する。比較的高速に実行される処理で、差分データ量が1G程度と大きくなっても数十秒程度で完了する。

ところで、CSVと一口に言ってもそのフォーマットには様々な亜種が存在する。区切り文字は何か？文字列はダブルクォーテーションで囲むか？日付表現形式はどうするのか？さらにはファイルエンコードはUTF8でよいか？圧縮形式はGZIP圧縮か？。CSVのフォーマットの亜種が個別のシステムごとに存在すると保守しずらくなる。Redshiftで利用するCSVだけでなく、システム全体で必ず標準化しておこう。copyコマンドには様々なCSVの形式をロードするためのオプションがついているので標準化したCSV形式に合わせて調整する。

③．ステージングレイヤのデータをオリジナルレイヤにアップサートする

ステージングレイヤにcopyコマンドで転送したデータをオリジナルレイヤにマージする。多くのテーブルには主キーが定義されているだろうから、ステージングレイヤとオリジナルレイヤのデータの主キーを比較すればそれが新しく挿入されたデータなのか更新されてデータなのかは判断できる。またRedshift内のテーブルの話なので、それぞれ新規データの差分を反映するSelect-Insertと、更新データ差分を反映するSelect-Updateを実行することでマージが実現できる。

実はこの①、②、③を１組として複数スレッドを使い、データの源泉となるシステムやテーブルに対して並列実行を行うことで転送時間を短縮することができる。ネットワーク帯域やRedshiftインスタンス種別によっても異なるだろうが、私のケースでは６〜８スレッド程度で同時に転送をすると最も転送時間を短縮することができた。最適なスレッド数は環境に依るのでいくらか試しながら数を調整していただければと思う。

また細かなテクニックではあるがデータ量の多いテーブルから並列にデータ転送を開始するようにするとクリティカルパスを短縮することができる。これは実行の最後の最後になってデータ量が多くて実行に時間がかかる処理が開始されて、それだけが単体実行される非効率な状態を防ぐことができるからだ。

④．オリジナルレイヤの有効期限を迎えたデータを除いてディープコピーを行う

オリジナルレイヤのデータは差分更新のためのマージinsertやupdateが行われる。そうすると未ソート領域にこれらのデータが溜まってクエリ速度が遅くなってしまう。こうした未ソート領域を開放するのがVacuumだ。だが、データ量が多くなった場合にはメモリを増やしても、Vacuumでエラーが発生してしまって実行させることができなくなるケースに遭遇した。それでVacuumを使うことは諦め、代わりとして利用したのがディープコピーと呼ばれる方法だ。要は全く同じスキーマの新しいテーブルを作ってそちらにSelect-Insertでデータを全件投入してしまうという方法だ。このときについでに有効期限切れたデータをコピー対象から外すことで、有効期限切れデータの削除の目的も達成できる。

なお、有効期限切れのデータはRedshiftから削除する前に、S3上に念のため保存しておくと安心だ。unloadコマンドで簡単に任意のクエリ結果をS3上に保存することができる。もちろん様々なCSV形式でエクスポートするためのオプションがあるので標準化したCSV形式に合わせて調整する。

RedshiftのSelect-Insertはとても早い。しかしディープコピーはデータを全件移動することになるのでやはりそれなりに時間のかかる処理になる。一方、未ソート領域があってもクエリが動作しなくるわけでもないし、一般ユーザからのクエリの対象はデータマートのレイヤであってオリジナルレイヤへ求める速度の優先は全く高くない。それぞれシステムの性質にも依るだろうが数日、場合によっては１ヶ月程度であっても、放置による動作の低下は大きな問題にならないかもしれない。私の場合には、ディープコピーを行うだけの時間が日次で確保可能だったので毎日ディープコピーを行ったが、週次などの実行でも問題にならないシステムが多いのではないかと思う。それぞれの状況に応じてディープコピーの頻度は調整すると良い。

ところで、この④からの処理は処理の主体がRedshiftに移り、Redshift自体に大きな負荷をかける。Redshiftは同時実行性能が低いので、これ以降の処理はシリアル実行としていた。

⑤．モデルレイヤのテーブルを導出する

これはオリジナルレイヤのデータからモデルレイヤのテーブルを導出する処理だ。だが、以前にも説明したようにモデルレイヤのテーブルはそのほとんどをビューとしていたので、実際にはほとんど処理がない。パフォーマンス上の理由からごく一部だけをビューではなくテーブルとしており、そのテーブルだけを導出するにとどめていた。

⑥．データマートレイヤのテーブルを導出する

これはモデルレイヤのデータからデータマートレイヤのテーブルを導出する処理だ。モデルレイヤはほとんどをビューで構成していたので、物理的にはオリジナルレイヤのデータが使われるが、モデルレイヤにて各種データが正規化されていればデータマートレイヤのテーブル導出が簡単に行える。

私の場合にはSelect-Insertを使ってテーブルのデータを全件を導出し直した。もちろんある程度時間はかかるが、RedshiftにとってSelect-Insertは得意な処理で、最も時間のかかるテーブルであっても20分程度で完了した。また全件導出によるディープコピーとなるので未ソート領域のないクエリに適したテーブルを導出できる。

テーブル導出の処理ステップ

テーブル導出する場合は、実はいくつかの処理ステップにて導出する必要がある。またディープコピーでもほぼ同様の処理ステップになる。

-- １.新テーブルを作成する
create table a_table_new ( DDL... );

-- ２.新テーブルに既存テーブルのデータを挿入する(有効期限内のもの)
insert into a_table_new (select * from a_table where 有効期限内...);

-- ３.新しいテーブルと古いテーブルを入れ替える
start transaction;
alter table a_table rename to a_table_old;
alter table a_table_new rename to a_table;
commit;

-- ４.新しいテーブルへ向き先が変わるようにビューを再定義する
create or replace view dependent_a_view as ( DDL... );
create or replace view dependent_b_view as ( DDL... );

-- ５.古くなったテーブルを削除する
drop table a_table_old;

わかりにくいのは、４.の新しいテーブルへと向き先を変えるためにビューを再定義しているところだろう。実はテーブル名を変更してもビューは古いテーブルへと向き先が自動で変わって新しいテーブルを参照してくれない。だから新しいテーブルを作ったら再度ビューを定義することで新しいテーブルへと向き先を変更する必要があるのだ。

なお、上記のステップを使えば、そのステップの実行のいずれの時点であっても、テーブルやビューへのクエリが利用できなくなることがない。

制御に必要な実行履歴テーブルとロックテーブル

細かな話ではあるが、データマートを構築するまでの制御プログラムの実行を実現するためには、実行履歴を保存しておくことが必要だ。差分データ連携を実現するには前回の実行日時を、連携するテーブルごとに保存しなければならない。この実行履歴には保守の目的を含めて、実行対象テーブル、挿入データ数、更新データ数、実行開始時刻、実行終了時刻、実行結果状態などを保存しておくとよい。

また、処理を行っているテーブルに対して、上記の制御プログラムが２重に実行されるなどした場合にはデータが破損しかねない。オンライン処理ならDBドランザクションを用いたロックで処理させるところだが、多量のデータをSelect-Insertで処理するこのようなプログラムでDBトランザクションを用いるのはあまり良い手とはいえない。処理中のテーブルを論理的にロックできるように、ロックテーブルを作ってプログラム中から必要に応じて状態を確認し、他のプロセスで処理中であればエラーとして処理を中断するなどさせると安心だ。特にオリジナルレイヤのデータの破壊だけは絶対に避けなければならない。

Redshift設計での個人的知見のまとめ　その２

2016-11-15T19:49:00.001+09:00

データ連携の３つのタイプ

データの源泉からデータを連携してオリジナルレイヤにマージする際のデータ連携には以下の３つのタイプがある。

・置換データ連携
・差分データ連携

・スナップショットデータ連携

置換データ連携

置換データ連携は、単純にデータを全件転送してオリジナルレイヤのデータをすべて置換してしまう最も単純な連携だ。データの少ないマスタデータや、後述する差分データ連携が利用できない場合に利用する。

差分データ連携

差分データ連携は、前回の連携時点から新しく挿入や更新が行われたデータのみを転送して、オリジナルレイヤのデータにマージを行う連携だ。最も利用頻度の高いデータ連携方法で特別なことがなければこれを利用するのが良い。ただし差分データ連携の利用にはには以下のようないくつかの制限がある。

・主キーが存在すること（存在しない場合には更新マージができない）
・最終更新日時が存在すること（更新されないデータの場合には登録日時が必要）

オリジナルレイヤへのデータのマージは、ステージングレイヤを通して行われる。主キーが必要なのは、ステージングレイヤとオリジナルレイヤのデータの主キーを比較すればそれが新しく挿入されたデータなのか更新されてデータなのかは判断できるからだ。それぞれ新規データの差分を反映するSelect-Insertと、更新データ差分を反映するSelect-Updateを実行することでデータのマージを行うことができる。

差分データ連携で最終更新日時が必要なのは、当然前回からの差分を判定するためであり、これが更新されないと連携が行われずにRedshift内に古いデータが存在することになる。Redshiftに更新が反映されるタイミングで必ず最終更新日時が変更されるのかはデータの源泉となるシステムの保守担当に十分に確認しておく必要がある。

例えば運用保守作業で直接SQLを実行した場合や、システムが補助的にステータスを更新するなどの場合には最終更新日時が更新されないなどのケースが起こりがちだ。もしもデータ源泉側のシステムが新規開発するものであったり改修が可能であれば、ユーザオペレーションによる最終更新日時と、システムが自動的に変更を行ったことによる最終更新日時とは分けて保持することをおすすめしたい。

スナップショットデータ連携

スナップショットデータ連携は、定時で取得したスナップショットのテーブルを累積していく連携だ。例えば、在庫テーブルには現時点の最新の在庫情報しか持っていないが、日次での変遷を分析したいといった場合に役に立つ。スナップショットデータ連携では、タイムシリーズテーブルを利用すると便利が事が多い、これは日次などの定期スナップショットごとに新しいテーブルを作成する。「ベーステーブル名＋日付」のようなテーブルが多量に作成されるので、これらのシリーズ化されたテーブルをすべてUNION ALLしたビューも同時に提供する。

タイムシリーズテーブルは、保存期間のはっきりしたテーブルに適用することがRedshift本家のページにも推奨されている。保存期間の切れたテーブルの削除はDeleteよりも高速であり、破損したブロックを作らないのでVacuumも不要だからだ。だが、差分データ連携の方でもにタイムシリーズテーブルを適用することには個人的に疑問を持っている。それは、タイムシリーズ自体がシステムを複雑にするし、Redshiftは更新可能ビューには対応していないので、挿入だけなら問題は少ないが更新する際にはビューの背後にあるテーブルにUpdateをかけなければならない。それにDeleteによる破損ブロックの問題は後述する保存期間内のデータのみに限定したディープコピーをすればよい問題だからだ。

対象データにもよるがスナップショットデータのテーブルはデータ量が多くなりがちなので使用には検討が必要なことがある。例えば、データの保持期間は日次で残す期間をどのくらいにするか、あるいは月次として保持する期間はどのくらいにするか、またそれらをどう組み合わせるかを設計する必要がある。また、単純な実装ではデータ源泉から全件を転送する方法が実現は簡単だが、前回からの更新分を転送することで保持するデータを削減する方法もある。

差分のみを転送する場合、基準となるスナップショットとそこからの差分データを利用して各時点のデータを導出することになるが、この歯抜けになった各時点のデータをBIツールから参照できるようにするためにクエリによって補完しなければならないことがある。また、基準となるスナップショット自体がデータの保持期限を過ぎた場合には。新しく基準となるスナップショットを作成することになる。差分による転送の実現は可能だが機構の複雑さはだいぶ増してしまう。

システムを運用していると、時には障害が発生する。置換データ連携や、差分データ連携ではデータ転送再開まで、しばらく古いままのデータがRedshiftにあるだけだが、スナップショットデータ連携では、それが必要とするその時にスナップショットを取れなければ情報は完全に失われてしまい、目的を達成できなくなってしまう。だからこの方式でのデータ連携では、Redshift自体はもちろんだが、データの源泉となるシステムに対しても信頼性の対策が求められることがある。また障害復旧時にはこれらのデータ連携から真っ先にデータ転送開始する必要がある。

この続きを読む　その３へ

Redshift設計での個人的知見のまとめ　その１

2016-11-14T01:21:00.000+09:00

はじめに

AWS Redshiftを利用したシステムの設計と開発を行ってきたので、そこで得た個人的な知見をまとめたいと思う。ここで書かれることは実際に２年間稼働させ続けたRedshiftシステムの中から得たもので、これからRedshiftを利用したシステムを開発する方にも、いくつかは役に立つことがあるのではないかと思う。ただし、これはある特定の顧客向けに設計したRedshfitシステムから得た知見であるために、すべてのシステムに適用できるものではないことに注意して欲しい。どのようなシステムでもそうだが、個別システムのそれぞれの要件に応じた設計の選択がいつでもシステム設計者には求められている。また、今回のシステムの顧客の特定につながる情報や競争力を損なう可能性のある情報については記述できないため、一般論として抜き出した知見であり、詳細をぼやかした文章となっている部分もあるがご容赦いただければと思う。

内容

内容は以下のとおり：

・システム概要

・システムの主な構成
・Redshift内のレイヤ構成
・データ連携の３つのタイプ
・データ収集とデータマート構築プログラム
・Redshiftテーブル設計の勘所
・パフォーマンスとキャパシティプランニング
・コード生成と自動化
・運用・監視

なお、Redshift自体の機能や特徴についてはAWSのドキュメントに十分に記述されているので、こうした基本的なドキュメントの内容は既に読んでいる方を前提としている。必要に応じてそちらを参照していただければと思う。

システム概要

基幹システムを構成する各サブシステムから日次でデータを収集して、データウェアハウスとデータマートをRedshift上に構築し、BIツール(tableauやqlikviewのような製品)で社内ユーザがデータを任意の視点で分析できるようにするシステムだ。

・基幹システムBIシステム
・日次連携
・データ総量約2.5T
・最大トランザクションテーブル
　　1億はいかないくらいのレコード数、100G程度

・アクティブユーザ数　1000人くらい
・インスタンスタイプ　dc1.large（20ノード程度）

システムの主な構成

Redshiftを中心として、その前にデータの源泉として基幹システムを構成する各サブシステムが存在し、その後にデータマートを参照するBIツール(tableauやqlikviewのような製品)が存在する。
そして、各サブシステムから日次でデータを収集してRedshiftにデータを転送し、またRedshift内でデータを加工してデータマートを構成するための制御を行うプログラムを稼働させている。

このプログラムは日次で動作すればよいのでAWS DataPipelineで日次でEC2インスタンスを起動して動作するJavaプログラムとしていた。実際のところこのプログラムはデータを収集しての転送とRedshiftへのSQLの発行が主で、それほどロジックとしては複雑なことはしないし、実行速度が求められることもない。だからJavaよりも生産性の高い言語を選択しても全く問題ない。また、詳細は後述するがこれらのロジックは決まりきった共通処理で構成されているので、データの転送元からデータマートのテーブルまでをマッピングできるDSLを定義してコード生成させることで、かなり大きな生産性の向上が期待できる部分でもある。

Redshift内のレイヤ構成

Redshift内は以下の４つのレイヤに分けて構成した：

・ステージングレイヤ
・オリジナルレイヤ
・モデルレイヤ
・データマートレイヤ

なお、このレイヤの名前はプロジェクト内で勝手に名付けたものなので一般的に使われているレイヤ名ではない。

ステージングレイヤ

ステージングレイヤは、転送してきたデータを一時的においておく場所だ。外部の各種サブシステムからS3を経由して取り込んだデータは一旦このステージングレイヤのテーブルにおいて、後続のオリジナルレイヤに対するマージを待つことになる。
特に各サブシステムからすべてのデータを転送していてはとても日次での連携が間に合わないため、前回取り込み時から新しく挿入や更新された差分データだけを転送することが多いだろう。この差分連携の場合には新しく挿入や更新されたデータが混在してここにまずは置かれることになる。

オリジナルレイヤ

オリジナルレイヤは、転送されてきた今までのデータを生のまますべて累積していく場所だ。生のままのデータをすべてここで維持することで、いつでもここから後続のモデルレイヤやデータマートレイヤのデータを任意の形式で（再）導出することができる。分析の要件に応じて変更が必要なデータマートにとって、導出ルールを変更して再導出することができることは大きなメリットだ。

オリジナルレイヤには、ステージングレイヤからのデータがマージされる。多くのテーブルには主キーが定義されているだろうから、ステージングレイヤとオリジナルレイヤのデータの主キーを比較すればそれが新しく挿入されたデータなのか更新されてデータなのかは判断できる。Redshift内のテーブルの話なのだから、それぞれ新規データの差分を反映するSelect-Insertと、更新データ差分を反映するSelect-Updateを実行すれば簡単にマージが実現できてしまう。

また長期にわたるデータ分析を可能にするために数年から10年程度にわたってデータが累積されることがある。そうするとデータ源泉となるサブシステムよりも保存期間が長いことになり、それでいつしかこのデータがシステム全体の中で「正のデータ」として扱われるようになることがある。だからオリジナルレイヤのデータの品質の確保はとても重要な問題だ。転送したデータが転送中に壊れることがないように十分なデータ転送プログラムの品質が確保される必要がある。

Redshift内に保存されているデータの信頼性については、Redshift自体に任せてしまうことが可能だ。シングルAZではあるもののデータは複数ノードにまたがってコピーされ、別リージョンのS3へとバックアップも行える。

モデルレイヤ

モデルレイヤは、オリジナルレイヤの生データを利用しやすいように十分に整理して正規化したデータをおいておく場所だ。例えば事業部を複数抱えている場合にはたとえ同じ種類のデータであってもシステムが別になっていてそれぞれから取得する必要があることがある。そのような場合には、オリジナルレイヤではシステムごとに別々のテーブルに生データとして保持しておき、モデルレイヤで共通フォーマットを定めてそれに合わせて変換を行い、UNION ALLするといったことを実施したりする。

この方法ではデータの源泉に対応したテーブルがRedshiftのオリジナルレイヤ内に作成されることになる。これはデータの源泉の変更がRedshift内にダイレクトに反映されるという意味で明らかなデメリットがある。だが、生データの保持していることはデータマートの構築に最大限の柔軟性をもたらしてくれる。私はデータマートの柔軟性を選択したが、何を選択するかは設計者次第だ。

また、モデルレイヤでは実データとしてデータを保つ必要は必ずしもないので、パフォーマンスなどの特別な理由がなければオリジナルレイヤのデータを使ってViewで実現するのがよい。これはモデルレイヤのデータの導出時間の短縮にも、データ容量の削減にもなる。

Redshiftのコストは主にインスタンスタイプとノード数によって決まってしまう。ではそれらを何によって決めるのかというと、１つは求めるクエリの速度で、もう１つはデータ容量だ。システムによるだろうが、私の関わったシステムではデータ容量の拡張のためにしかノードの追加を行ったことがなかったし、モデルレイヤはほとんどすべてViewとしていた。コスト削減のためには常にデータ容量の増加を抑えるように気を配っておく必要がある。

データマートレイヤ

データマートレイヤは、BIツール(tableauやqlikviewのような製品)から利用しやすいように加工したデータをおいておく場所だ。どのようなテーブルとするかは、主にBIツールとデータマート側との責務の分割の方針と、求めるパフォーマンスから判断する。このテーブルは、生データにより近いテーブル構造から、実際にBIツールで参照されるデータにほとんど特化したテーブル構造まで様々な集計レベルを行っておくことが考えられる。具体的には予めジョインをしておいたり、期間や組織ごとに集計しておいたりといったことだ。

個人的には、ここでのテーブルはすべてジョイン済みのテーブルとし、パフォーマンスが許すならジョイン済みのビューとして定義することをお勧めする。

システムによるだろうが、私の関わったシステムでは、パフォーマンスを向上させるためにジョインを避け、トランザクションに対するマスタはすべてデータマートではジョイン済みとした。私の経験上では５つ程度のテーブルを事前にジョインしたデータマートの場合には１０倍程度高速にクエリを実行できる。Redshiftは対象のクエリを全ノードを使って全力で短時間に実行することができるのが特徴のシステムで、逆に言えば全くといっていいほど同時実行性能を持っていない。だからクエリを１０倍高速にできるというなら、１０倍のスループットを実現できるということであり、そして１０倍のアクティブユーザをさばくことができるということだ。

データマートレイヤのテーブルは様々な特化のレベルがありえるが、１つ覚えておきたいのが、生データから離れてBIツールで参照されるデータにより特化したテーブルであるほど、キャッシュに置換わる可能性が高まることだ。このキャッシュというのは単純にExcelの集計レポートとして出力されたものから、Redisをつかったものまで様々だ。こうしたキャッシュはRedshiftへの負荷を削減できるだけではなく、特定用途へ過度に特化したテーブルの増加を防ぎ、Redshiftの保守コストを抑えることにも役立つ。

この続きを読む　その２へ

ViewModel設計の原則　その４

2012-06-24T15:08:00.000+09:00

□導入

前回までは比較的ViewModel設計の位置づけ的な説明を行ってきました。今回からはとうとうViewModel設計の方法に関する原則について説明していきます。

今回のブログでは、４～６番目の原則として「あらゆる画面の状態をViewModelでの状態としてモデル化すること」、「イベントではなく、ViewModelの状態によって画面を制御すること」、「いつでもViewを再構成できるだけの情報をViewModelに保持させること」をそれぞれ順番に説明します。

なお、ここでの説明がどのプロジェクトにも適用可能な正しい内容であるかは分からないことをあらかじめご承知おきください。ここでの内容をそれぞれのプロジェクトで使用するのはもちろん構いませんが、すべて自己責任でお願いします。

□ViewModel設計ではオブジェクト指向モデリングの知識が生かせる

ViewModel設計の特徴は、一般的なモデリングの多くがビジネスドメインを対象としているのに対して、そのモデリング対象が画面自体であるということです。

実のところモデリング対象が画面自体であるということを除けば、他のオブジェクト指向モデリングと大きく異なる点はそれほどなく、ビジネスドメインやその他のクラス設計でのオブジェクト指向設計の開発経験をほぼそのまま生かすことができます。ある程度の設計経験者であれば、若干のコツをつかむだけでViewModel設計を行えるようになるようです。

リッチなＵＩでは複雑な画面状態や振る舞い、そしてオブジェクト間の協調が必要とされます。このためむしろ、ビジネスドメインの設計よりも、カプセル化、継承、ポリモーフィズムといったオブジェクト指向の技術をフルに生かすことができる場でもあります。

オブジェクト指向の技術はViewModel設計のための基礎であり、とても重要ではありますが、本ブログでの範疇を超える内容ですので、その説明については割愛します。既に多くの良書（※１）が存在しますので、詳細はそちらをご覧ください。

それでは、ViewModel設計の原則について見ていきましょう。

※１：ViewModel設計で役立つ良書としてひとつだけ紹介すると、「実践ＵＭＬ」が挙げられます。この中で紹介されているGRASPパターンは、実際のプロジェクトでうまく適用できる状況というのは少ないと思うのですが、面白いことにViewModelの設計では参考になります。

□MVVMではViewModelを通して画面をコントロールする

ある画面、特にリッチなＵＩを思い浮かべたとき、画面の中にはあらゆる要素が含まれます。具体的には、ラベルやテキストボックスといったＵＩコントロール、表示データ、入力データ、表示ページ、タブ、ダイアログ、そしてフォント、色彩、アニメーションといったものです。そしてこれらが、ユーザの操作やその他によって変化しながら全体として画面が動作します。

MVVMでは、こうした刻々と変化する、画面のあらゆる状態を満たすようにViewModelを設計します。そしてさらにいえば、フォントや色彩といったデザインの部分は切り捨て、プレゼンテーションロジックとも呼ばれる画面の本質のみがViewModelに含まれるようにします。

この画面の本質であるViewModelから、フォントや色彩を含む実際の画面を構築するのはViewの役割となります。この意味で、Viewは「ViewModelから画面を生成する変換器」のようなものともいえます（具体的にはデータバインドや、データテンプレート、データトリガ―などで実現します）。

さらにViewは、アプリケーションの実行時にViewModelの状態を常に監視しているため、ViewModelへの変更は即座に画面へと同期します。

こうしてMVVMでは、ViewModelのプロパティや関連の変更すれば、画面をコントロールすることができます。このため些末なことに煩わされずに画面の本質に対してプログラミングできるのです。

□[原則４]あらゆる画面の状態をViewModelでの状態としてモデル化すること

このようにMVVMでは、画面の本質であるViewModelに対してプログラミングすることによって画面をコントロールできます。しかし逆に言えば、ViewModelを通してしか画面をコントロールすることが（基本的には）できないということでもあります。ですから、MVVMではあらゆる画面の状態をViewModelの状態としてモデル化することが求められます。

実は画面の状態は、とりわけViewModelのデータ構造（プロパティや関連）によって定義されます。つまり、「あらゆる画面の状態を満たすように、ViewModelのプロパティや関連といったデータ構造が設計されなければならない」ということになります。

ちなみに、処理を司るViewModelのメソッド(より正確にはコマンド)内には画面の状態というものは存在しません。ViewModelのメソッドは、ある画面の状態を別の画面の状態に変更、あるいは遷移させる役割を持ちます。

それでは、具体的にどういったものがViewModelのプロパティや関連となるのかについて、以下にいくつかの例を列挙します。

＜ViewModelのプロパティ＞
・画面表示項目の内容（ラベルの内容など）
・画面入力項目の内容（テキストボックスの内容など）
・画面項目のEnable,Disable,ReadOnly

・画面項目を強調するかどうかのフラグ

＜ViewModelの関連（関連の先にViewModelのオブジェクトがある）＞

・子供のページやタブViewModel

・子供の画面部品ViewModel
・他のViewModelへの参照

ViewがＵＩコントロール、フォント、色彩、アニメーションなどを保持し、ViewModelではプレゼンテーションロジックへと抽象化された分だけ、シンプルになっていることが読み取れると思います。また、ViewModeｌは関連を通して子供のViewModelを保持したり、他のViewModelを参照したりすることで、全体としてグラフ構造を構築することもあることに注意してください。

そのほか、例えば郵便番号、都道府県、市区町村、番地などのプロパティを持った住所ViewModelのような、共通的な画面部品ともなるようなViewModelを関連に保持するようなケースもあります。

ところで、あくまで上記のものは代表的な例だけであることにご注意ください。これ以外のものであっても理由があれば追加することはまったく問題ありません。何を画面の状態としてモデル化するかは、ViewModelの設計者が画面の本質にとって何が重要と考えるかに依るのです。

[原則４]あらゆる画面の状態をViewModelの状態としてモデル化すること

□[原則５]イベントではなく、ViewModelの状態によって画面を制御すること

MVVMでは、画面の状態がViewModelの状態としてモデル化されます。このため、画面の状態を変えるためには、ViewModelの状態を変更すればよいのでした。

具体的には、MVVMのアプリケーションがボタン押下などのイベントを受けると、以下のような順番をとおして画面に反映されます。

１．ボタンが押下される。
２．ボタン押下に対応したViewModelのメソッド（正確にはコマンド）が呼び出される
３．（必要に応じて、ViewModelのメソッド内で、Modelへのデータ変更や、データ取得が行われる）
４．ViewModelのメソッド内で、ViewModelの状態（プロパティや関連）が変更される
５．Viewの機能（データバインド、データテンプレート、データトリガ―など）によって、ViewModelの状態変更に対応して画面の状態が変更される

ここで重要なのは、４．にあるように、ViewModelのメソッドでは、ViewModelの状態（プロパティや関連）を変更するまでしか行なわないことです。必ずViewModelの状態を通して画面の状態を変更するようにします。

MVVMの学びたての時には、ViewModelの状態変更を通さずに、イベント発生後のViewModelのメソッドから直接画面（つまりView）を変更する方法はないのかと、そればかり試みようとしてしまうようです。しかし、これは多くの場合には誤りです。

実はViewModelの状態変更を通さずに、ViewModelのメソッドから画面を直接操作することは、メッセンジャーと呼ばれる方法やその他の方法を使用すれば不可能ではありません。しかしそれでは、ViewModelからその画面の状態を把握する方法がなくなってしまいます。そしてその画面の状態を制御できなくなってしまうのです。

つまり、ViewModelのメソッド内では、ViewModelのプロパティや関連を変更するだけであり、Viewを直接変更するようなことは基本的に行いません。ViewModelの状態から実際の画面の生成を行い、その状態を同期し続けるのはViewの役割となります。

[原則５]イベントではなく、ViewModelの状態によって画面を制御すること

□[原則６]いつでもViewを再構成できるだけの情報をViewModelに保持させること

原則として、「あらゆる画面の状態をViewModelでの状態としてモデル化すること」と、「イベントではなく、ViewModelの状態によって画面を制御すること」をみてきました。そして、少し前に説明したように、ViewはViewModelから画面を生成する変換器の役割を持つにすぎません。

これらのことを合わせて考えてみると実は、Viewがいついかなるタイミングでなくなってしまったとしても、「View再構成できるだけの十分な情報をViewModelに保持させ、常に同期させておく」必要があることが分かります。

これは原則というよりも、折に触れて振り返るべきテストとでもいうべきものです。ViewModelのモデル化の際に、これを自問自答することで、とある画面の状態をViewModelのプロパティや関連として定義しておくべきなのかどうかの判断基準となります。

なお、Viewが仮になくなってしまっても再構成する必要がない状態もあるでしょう。

例えば、カーソルに応じて表示されるツールチップの表示・非表示の状態や、ちょっとしたデザインのためのアニメーション実行中の画面の状態（揮発性の状態）であれば、Viewとしてあらためて再構成したいなどと思わない状態ですし、それをViewModelで制御したいとも思わないでしょう。それは、それだけ些細で重要ではない画面の状態だということです。そうしたものをViewModelの状態として定義する必要はないのです。

画面の状態として制御したいものをViewModelでの状態として定義してください。また、ViewModelの状態として定義を行わないことで、それは些細で重要ではない画面の状態であるということを表現してください。

[原則６]いつでもViewを再構成できるだけの情報をViewModelに保持させること

□まとめ

今回のブログでは、ViewModelのデータ構造（プロパティや関連）によって画面の状態をモデル化し、ViewModelのメソッドではViewModelのデータ構造に対して変更を行うことで画面を制御するということを説明しました。

そして、「いつでもViewを再構成できるだけの情報がViewModelに保持されているかどうか」という、ViewModel設計の妥当性をチェックする簡単なテストについても説明しました。

実はこれらの原則は、言うは易く行うは難しです。これらの原則に「完全に」沿うことは、実際にやってみるとメンドクサイですし、場合によっては実現が困難なこともあります。

私自身、ひとつのアプリケーションの中でも、重要な箇所では、可能な限り上記の原則に沿うように開発を行いますが（場合により自作のビヘイビアを作成することもあります）、それ以外の部分ではコストとメリットを天秤にかけて、原則に沿わないで開発することもしばしばです。ですから、あまりにも厳格に上記の原則を守る必要がないことについては覚えておいてください。

なお、こうしたことが、MVVMのライブラリやフレームワークの成熟によって解決されるのか、そもそもMVVMの完全な適用など目指すべきものではなく、コストとメリットを天秤にかけて、部分部分にMVVMを適用していくのが適切なのかは、私自身まだ判断できていません。

私が今回紹介した原則は、MVVMが目指すべき理想にすぎないともいえます。しかし、目指すべき原則があることで、何を例外として回避し、何が解決すべき課題であるのかがハッキリと見えるようになるはずです。

MVVMでの開発に困難がないわけでもありませんが、あまりストイックに考えずに、時にはMVVMの課題をさらりと避けて、楽しいMVVMライフをお過ごしください。

長文お疲れ様でした。

以上。

MVVMでメッセンジャーを使わずにダイアログを表示する(MVVM Dialog Behaviorライブラリ提供)

2011-12-28T19:32:00.000+09:00

□導入

MVVMでのダイアログ表示では、メッセンジャーを使用することが一般的となっています。しかし、メッセンジャーは理解が難しく、扱い方が煩雑であるために、MVVMを使用すべきでないという理由のひとつにさえなっていました。

私自身、MVVM自体は使える技術だと思っているものの、メッセンジャーを使用してダイアログ表示を行うこと自体については疑問を感じており、以前、私のブログにて、メッセンジャーを使わずにシンプルにダイアログ表示を行う方法を「MVVMでダイアログ表示のためにメッセンジャーを使用するのはおかしいのでは？」と題してご紹介もしましたが、あくまでこの時点では方向性の提案にとどまるものでした。

しかし、この度「MVVM Dialog Behavior（http://mvvmdialogbehavior.codeplex.com）」と呼ぶ、ダイアログ表示のためのライブラリを作成いたしましたので、今回のブログではその思想と使い方について解説します。

実は、ライブラリとはいってもたった２クラスで、全体でも200行程度しかなく、むしろコードスニペットとでもいうべきものです。このためライセンス自体を完全フリー（放棄）としますので、CodePlexでDLLをダウンロードして使用するなり、コードをコピーペーストして使うなりと自由にお使いいただければと思います。ただし、無保証ですので自己責任での使用をお願い致します。

□MVVM Dialog Behaviorの思想

MVVMではViewModelに画面状態を保持し、ViewModelの状態を変化させることでViewを制御します。

一方、メッセンジャーを使用する方法は、処理の起動であって、あくまでイベントを送るようなものであり、これ自体は画面状態とは相容れない考え方です。また、View を起動してそこで処理を行うので、ViewModelがViewへとダイアログ表示制御の責任を放棄してしまうような面があります。つまり、メッセンジャーによるダイアログ表示は、ViewModelにて画面状態を保持して画面を制御するというMVVMの基本的な姿勢に反するところがあるのです。

MVVM Dialog Behaviorでは、「ダイアログ表示という状態も画面状態の一部であり、このためViewModelの状態変化によって制御されるべきである。」と考えており、「ダイアログ表示を画面状態としてモデル化する」という思想のもとに作成されました。

何とも分かりづらいかもしれませんが、実は表示するコンテンツをViewModelの状態として保持して制御するのは、そこかしこで当たり前のように行われていることです。例えば、ラベルやボタンのコンテンツも、Metro UIのタイルのコンテンツも、MVVMならViewModelで管理するはずです。それらと同様のプログラミング体験でダイアログ表示を扱えるようにすべきだといっているだけだったりします。

単に、ラベルやボタンやタイルのコンテンツと同様にダイアログも扱うためのビヘイビアをライブラリとして提供したもの、それがMVVM Dialog Behaviorというライブラリです。

□MVVM Dialog Behaviorのメリット

MVVM Dialog Behaviorでは、ダイアログ操作にメッセンジャーではなくダイアログに対応したViewModel自体を使用します。そしてこのダイアログViewModelインスタンスを、親ViewModelのプロパティにセットすることでダイアログ表示を行い、Nullをセットすることでダイアログを閉じます。

またダイアログViewModelのプロパティを通してダイアログへのデータの引き渡しと結果の取得を行うことができます。このようにViewModel主導で、より直感的にダイアログを制御することができます。

そして、ダイアログの定義にViewとViewModelをしますので、メッセンジャー（およびメッセージおよびアクション）を使用するよりも見た目や機能をより簡単かつ柔軟に変更することができます。

MVVM Dialog Behaviorを使用することによるメリットには以下のようなものがあります。

ラベルやボタンやMetro UIのタイルのコンテンツ操作と同様のプログラミング体験で、ダイアログ表示を行うことができる。

ダイアログViewModelインスタンスを親ViewModelのプロパティにセットするだけでダイアログを表示を行える。また、Nullをセットするだけでダイアログを閉じることができる。
ダイアログ用ViewModelのプロパティを通してデータの引き渡しと結果の取得が行える。

ViewとViewModelを使用して柔軟にダイアログの見た目や機能を変更することができる。
ダイアログの種類を増やすのために、メッセンジャーのように専用のアクションや専用のメッセージを作成する必要がなく、ViewとViewModelの記述だけで完結させることができる。
ダイアログ表示状態が明示的にViewModel構造に表現されるため、ダイアログ表示中かどうかをViewModel内で容易に判断できる。またこれを用いて、システムの都合によりダイアログを強制的にクローズすること容易にできる。
ダイアログ表示のプレゼンテーションロジックがViewModelに含まれるようになり、自動単体テストコードによる検証が行いやすい。

□MVVM Dialog Behaviorの動作環境およびインストールについて

本ライブラリの動作環境は以下の通りです。

WPF4でのみ動作
Blend SDK ライブラリ(無償)が必要

Microsoft Expression Blend 4 Software Development Kit (SDK) for .NET 4

インストールについては以下の通りです。

本ライブラリのライセンスについて

Code Plexでは、MITライセンスを選択していますが、それ以上ゆるいライセンスが選択できなかっただけであり、ライセンス自体は完全に放棄します。MITライセンスでも本来必要な「著作権表示の保持」なども不要です。ただし、[免責]このソフトウェアを原因として発生した損失や損害については一切の責任を負いません。すべて自己責任でお願いします。
本ライブラリのダウンロードについて

Code Plexのサイトからダウンロード可能です。

[DLLの場合]

以下のURLから「MvvmDialogBehavior.dll」をダウンロード可能です。
http://mvvmdialogbehavior.codeplex.com/releases/view/80095

[直接ソースコードをコピーして取り込む場合]

以下のURLのソースコード(MvvmDialogBehavior.cs)をコピーしてプロジェクトに取り込んでください。ソースコードは自由に改変可能です。
http://mvvmdialogbehavior.codeplex.com/SourceControl/changeset/view/7708#113961

□MVVM Dialog Behaviorのサンプルコード

MVVM Dialog Behaviorの概念ばかり説明されてもあまりイメージが湧かないでしょうから、そろそろサンプルコードを見ながら説明していくことにします。このサンプルではViewModelの作成にMVVM Light Toolkit（http://mvvmlight.codeplex.com/）を使用して説明しますので、他のMVVMフレームワークを使用している場合には適宜読み替えてください。

以下のような簡単な画面からログインダイアログが表示されるというシナリオを考えてみましょう。

メインウィンドウ

ログインダイアログ（メインウィンドウのOpenDialogボタン押下時に起動する）

次にViewModelを見てみます。まずはViewModelのクラス図を見てみましょう。

ViewModel構造

メインウィンドウ用としてMainViewModelがあり、ログインダイアログ用としてLoginDialogViewModelがあります。そして、MainViewModelはDialogプロパティによって（ViewModelBaseを通して間接的に）LoginDialogViewModelを保持します。

このDialog プロパティの多重度が「0,1」となっているところがポイントです。これは、ダイアログが表示されているかどうかを、DialogViewModelのインスタンスが存在するか、Nullかによって判断するというモデルになっています。つまり、ダイアログ表示のためには、Dialogプロパティに DialogViewModelのインスタンスをセットし、またダイアログを閉じるにはNullをセットすれば良いことになります。

このように、ViewModelの状態変更によってダイアログ表示を制御できるのは、ダイアログ表示状態そのものがViewModelのクラス構造の中にモデル化されているからです。ここはMVVM Dialog Behaviorの思想がよく表れている部分です。

それではViewModelのコードを見てみましょう。まずは、MainViewModelのソースコードを見てみます。

MainViewModelのソースコード

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using GalaSoft.MvvmLight;
using System.Windows.Input;
using GalaSoft.MvvmLight.Command;

namespace MvvmDialogBehaviorSample
{
    public class MainViewModel:ViewModelBase
    {
        public MainViewModel()
        {
        }

        private ViewModelBase _Dialog;
        public ViewModelBase Dialog
        {
            get { return _Dialog; }
            set
            {
                if (_Dialog != value)
                {
                    _Dialog = value;
                    RaisePropertyChanged("Dialog");
                }
            }
        }

        private ICommand _OpenDialogCommand;
        public ICommand OpenDialogCommand
        {
            get { 
                if (_OpenDialogCommand == null)
                {
                    _OpenDialogCommand = new RelayCommand(OpenDialog);
                }

                return _OpenDialogCommand;
            }
        }

        private void OpenDialog()
        {
            // Open Dialog
            Dialog = new LoginDialogViewModel(CloseDialog) { UserName="LastLoginUser1" };
        }

        private void CloseDialog()
        {
            // Close Dialog
            Dialog = null;
        }
    }
}

注目すべきは、ダイアログオープンのために、Dialogプロパティへのインスタンスのセットしか行っていないことです。そして、CloseDialog()メソッドにて、ダイアログクローズのために、DialogプロパティにNullのセットしか行っていません。

また、ダイアログに引き渡すべきユーザ名がViewModelプロパティによる単純な受け渡しで実現できています。

ところで、ここで問題になるのが、そもそもどうやってこのCloseDialog（）メソッドを呼び出すのかということです。ここでは、ダイアログ側からのクローズを考慮して、このメソッド自体をLoginDialogViewModelのコンストラクタに渡してコールバック可能にしていることに注意してください。このあたりの実装方法は、他にもいろいろ考えられます（＊１）ので、それぞれのプロジェクトに合わせて実装していただければと思います。

＊１：ほかの実装方法としては例えば、ダイアログViewModelにクローズイベントを作成して、ダイアログの呼び出し元ViewModelからイベントハンドラとしてをCloseDialog()をあらかじめ登録しておき、ダイアログViewModel側でクローズしたいときにイベントを発火させてクローズさせる方法も考えられます。

次に、LoginDialogViewModelのソースコードを見てみます。

LoginDialogViewModelのソースコード

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using GalaSoft.MvvmLight;
using System.Windows.Input;
using GalaSoft.MvvmLight.Command;
using System.Windows;

namespace MvvmDialogBehaviorSample
{
    public class LoginDialogViewModel:ViewModelBase
    {
        private Action _CloseAction;

        public LoginDialogViewModel(Action closeAction)
        {
            _CloseAction = closeAction;
        }

        private String _UserName;
        public String UserName
        {
            get { return _UserName; }
            set
            {
                if (_UserName != value)
                {
                    _UserName = value;
                    RaisePropertyChanged("UserName");
                }
            }
        }

        private String _Password;
        public String Password
        {
            get { return _Password; }
            set
            {
                if (_Password != value)
                {
                    _Password = value;
                    RaisePropertyChanged("Password");
                }
            }
        }

        private ICommand _LoginCommand;
        public ICommand LoginCommand
        {
            get
            {
                if (_LoginCommand == null)
                {
                    _LoginCommand = new RelayCommand(Login);
                }

                return _LoginCommand;
            }
        }

        private void Login()
        {
            if (DoLogin())
            {
                _CloseAction();
            }
        }

        private ICommand _CancelCommand;
        public ICommand CancelCommand
        {
            get
            {
                if (_CancelCommand == null)
                {
                    _CancelCommand = new RelayCommand(Cancel);
                }

                return _CancelCommand;
            }
        }

        private void Cancel()
        {
            _CloseAction();
        }

        private bool DoLogin()
        {
            // Login Process...
            return true;
        }
    }
}

ログインダイアログとして、ユーザ名とパスワードのプロパティを持ち、またログインとキャンセルのコマンドを持っています。たいしたコードでもありませんが、先ほど説明したとおり、自身のダイアログをクローズするために、MainViewModelから渡されたCloseDialog()メソッドをコールバックしている点はご注意ください。

これで、ViewModel側のソースコードの説明は終了です。次に、View側のソースコードを見てみます。

MainWindowのソースコード

<Window x:Class="MvvmDialogBehaviorSample.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:MvvmDialogBehaviorSample"
        xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
        xmlns:cmd="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras.WPF4"
        xmlns:mvvmdialogbehavor="clr-namespace:MvvmDialogBehavior;assembly=MvvmDialogBehavior"
        Title="MainWindow" Height="275" Width="375" Background="Azure">
    <Window.DataContext>
        <local:MainViewModel />
    </Window.DataContext>

    <i:Interaction.Behaviors>
        <mvvmdialogbehavor:DialogBehavior Content="{Binding Dialog}" >
            
            <mvvmdialogbehavor:DialogBehavior.Resources >
                <DataTemplate DataType="{x:Type local:LoginDialogViewModel}" >
                    <Grid Height="250" Width="350" Background="Ivory">
                        <Label Content="LoginDialogView" Height="29" HorizontalAlignment="Left" Name="label1" VerticalAlignment="Top" />
                        <Label Content="UserName" Height="29" HorizontalAlignment="Left" Margin="22,70,0,0" VerticalAlignment="Top" />
                        <Label Content="Password" Height="29" HorizontalAlignment="Left" Margin="22,112,0,0" VerticalAlignment="Top" />
                        <TextBox Text="{Binding UserName}" Height="24" HorizontalAlignment="Left" Margin="96,72,0,0" VerticalAlignment="Top" Width="120" />
                        <TextBox Text="{Binding Password}" Height="24" HorizontalAlignment="Left" Margin="96,114,0,0" VerticalAlignment="Top" Width="120" />
                        <Button Content="Login" Command="{Binding LoginCommand}" Margin="61,157,189,39" />
                        <Button Content="Cancel" Command="{Binding CancelCommand}" Margin="167,157,83,39" />
                    </Grid>
                </DataTemplate>
            </mvvmdialogbehavor:DialogBehavior.Resources>
            
            <mvvmdialogbehavor:DialogBehavior.Style>
                <Style TargetType="Window">
                    <Setter Property="SizeToContent" Value="WidthAndHeight"/>
                </Style>
            </mvvmdialogbehavor:DialogBehavior.Style>
            
        </mvvmdialogbehavor:DialogBehavior>
    </i:Interaction.Behaviors>
    
    <Grid>
            <Button Content="Open Dialog" Command="{Binding OpenDialogCommand}" Height="49" HorizontalAlignment="Left" Margin="88,83,0,0" Name="button1" VerticalAlignment="Top" Width="160" />
    </Grid>
</Window>

このMainWindowのコードには、メインウィンドウとログインダイアログのViewの定義の両方が記述されています。また、ログインダイアログの定義では、MVVM Dialog Behaviorが提供するDialogBehaviorクラスが使用されています。

ここで使用されているDialogBehaviorクラスのプロパティである、Content、Resources、Styleは、実は意図的にWindowクラスが持つプロパティと同名となっています。そしてこれらは、ダイアログの実体であるWPFのWindowインスタンスのプロパティにそのまま適用されることになります。

ただし実は、Contentプロパティだけは少し特別な扱いを受けています。通常は、ここにダイアログViewModelをバインディングするようにして使用するのですが、このダイアログのViewModelが存在している間のみダイアログが表示され、Nullの時にはダイアログは非表示となるようになっているのです。

これは、ViewModel側でダイアログが表示されるかどうかを、ダイアログのViewModelのインスタンスが存在するかNullかで表現するとした、ViewModelの定義とうまく適合するようになっています。

さて、先ほども説明したとおり、DialogBehaviorビヘイビアのResourcesとStyleのプロパティは、そのままダイアログのWindowインスタンスのプロパティへと設定されます。それ以上の働きはしませんが、サンプルコードの内容については少し説明しておきましょう。

今回のサンプルのResourcesプロパティにはDataTemplateが指定されています。このDataTemplateは、ViewModelとViewをマッピングする役割があります。DataTypeプロパティにViewModelの型を指定して、さらにViewを記述するのです。このようにしておくと、ContentプロパティのViewModelの型によって自動的にViewが適用され、またViewとViewModel間のDataContextの設定も自動的に行われます。

今回のサンプルコードでは、LoginDialogViewModelインスタンスがContentプロパティに設定されたときに、Grid以下のコントロールがViewとして適用されることになります。

次に、 Styleプロパティでは、WindowのSizeToContentプロパティにWidthAndHeightを指定しています。このため、内部のViewの縦横の幅に合わせてダイアログのWindowの縦横の幅となります。

以上でサンプルの説明は終了です。シンプルにダイアログ表示が実現できていると思いませんか。

□もっと実践的にMVVM Dialog Behaviorを使う　１　（Viewの共通化）

比較的単純にMVVM Dialog Behaviorを使用するサンプルコードをご説明してきました。しかし、実際のプロジェクトでは、もっとコードの共通化と再利用を推し進めることで、MVVM Dialog Behaviorに指定するコードはさらにシンプルなものになります。

まず、ログインダイアログのViewを共通化するところから見ていきましょう。

現在は、ログインダイアログのViewがDataTemplate内にインライン記述されています。しかし、複数の場所からログインダイアログを使用したい場合に、それぞれの場所でインラインに記述していては、コードの重複が発生することになるでしょう。

この問題を解決するためにログインダイアログのViewを共通化しましょう。といってもViewの共通化とは、単純にLoginDialogView.xamlファイルを作成して、DataTemplate内に記述していたXAMLコードを移動するだけです。

LoginDialogView.xamlの内容は以下のようになります。

LoginDialogViewのソースコード

<UserControl x:Class="MvvmDialogBehaviorSample.LoginDialogView"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
             xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
             xmlns:cmd="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras.WPF4"
             xmlns:mvvmdialogbehavor="clr-namespace:MvvmDialogBehavior;assembly=MvvmDialogBehavior"
             mc:Ignorable="d" 
             d:DesignHeight="238" d:DesignWidth="338"  >


    <Grid Height="250" Width="350" Background="Ivory">
        <Label Content="LoginDialogView" Height="29" HorizontalAlignment="Left" Name="label1" VerticalAlignment="Top" />
        <Label Content="UserName" Height="29" HorizontalAlignment="Left" Margin="22,70,0,0" VerticalAlignment="Top" />
        <Label Content="Password" Height="29" HorizontalAlignment="Left" Margin="22,112,0,0" VerticalAlignment="Top" />
        <TextBox Text="{Binding UserName}" Height="24" HorizontalAlignment="Left" Margin="96,72,0,0" VerticalAlignment="Top" Width="120" />
        <TextBox Text="{Binding Password}" Height="24" HorizontalAlignment="Left" Margin="96,114,0,0" VerticalAlignment="Top" Width="120" />
        <Button Content="Login" Command="{Binding LoginCommand}" Margin="61,157,189,39" />
        <Button Content="Cancel" Command="{Binding CancelCommand}" Margin="167,157,83,39" />
    </Grid>
</UserControl>

これに伴って、MainWindowのDataTemplateは以下のような記述に変更することになるでしょう。

MainWindowのソースコードの抜粋（LoginDialogView.xaml適用）

    <i:Interaction.Behaviors>
        <mvvmdialogbehavor:DialogBehavior Content="{Binding Dialog}" >
            
            <mvvmdialogbehavor:DialogBehavior.Resources >
                <DataTemplate DataType="{x:Type local:LoginDialogViewModel}" >
                    <local:LoginDialogView />
                </DataTemplate>
            </mvvmdialogbehavor:DialogBehavior.Resources>
            
            <mvvmdialogbehavor:DialogBehavior.Style>
                <Style TargetType="Window">
                    <Setter Property="SizeToContent" Value="WidthAndHeight"/>
                </Style>
            </mvvmdialogbehavor:DialogBehavior.Style>
            
        </mvvmdialogbehavor:DialogBehavior>
    </i:Interaction.Behaviors>

これで少しDialogBehavior内の記述が簡単になりました。

□もっと実践的にMVVM Dialog Behaviorを使う　２　（App.xamlへDataTemplate移動）

次に、このDataTemplateによるViewModelとViewのマッピングは、システム全体に対して１つあれば事足りることが多いでしょう。そうなると、このDataTemplateによるマッピングはApp.xamlに記述してしまえば良いことになります。

App.xamlのソースコード

<Application x:Class="MvvmDialogBehaviorSample.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:local="clr-namespace:MvvmDialogBehaviorSample"
             StartupUri="MainWindow.xaml">
    <Application.Resources>
        <DataTemplate DataType="{x:Type local:LoginDialogViewModel}">
            <local:LoginDialogView />
        </DataTemplate>
    </Application.Resources>
</Application>

これに伴って、MainWindowのDialogBehaviorからResourcesの記述も不要となります。

MainWindowのソースコードの抜粋（App.xamlへDataTemplate移動）

    <i:Interaction.Behaviors>
        <mvvmdialogbehavor:DialogBehavior Content="{Binding Dialog}" >
            
            <mvvmdialogbehavor:DialogBehavior.Style>
                <Style TargetType="Window">
                    <Setter Property="SizeToContent" Value="WidthAndHeight"/>
                </Style>
            </mvvmdialogbehavor:DialogBehavior.Style>
            
        </mvvmdialogbehavor:DialogBehavior>
    </i:Interaction.Behaviors>

□もっと実践的にMVVM Dialog Behaviorを使う　３　（WindowのStyleの移動）

これでかなりDialogBehaviorも単純になりましたが、よくよく考えるとStyleのプロパティも、それぞれのダイアログ種別に応じて指定するものであるため、MainWindow.xaml内ではなく、LoginDialogView.xaml内に記述できたほうがよさそうです。

こうしたことから、MVVM Dialog Behaviorでは、「WindowStyleBehavior」クラスを提供しています。これを使用すると、LoginDialogView.xamlは以下のようなコードとなります。

LoginDialogViewのソースコード（WindowStyleBehavior適用）

<UserControl x:Class="MvvmDialogBehaviorSample.LoginDialogView"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
             xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
             xmlns:cmd="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras.WPF4"
             xmlns:mvvmdialogbehavor="clr-namespace:MvvmDialogBehavior;assembly=MvvmDialogBehavior"
             mc:Ignorable="d" 
             d:DesignHeight="238" d:DesignWidth="338"  >
    
    <i:Interaction.Behaviors>
        <mvvmdialogbehavor:WindowStyleBehavior>
            <mvvmdialogbehavor:WindowStyleBehavior.Style>
                <Style TargetType="Window">
                    <Setter Property="SizeToContent" Value="WidthAndHeight"/>
                </Style>            
            </mvvmdialogbehavor:WindowStyleBehavior.Style>
        </mvvmdialogbehavor:WindowStyleBehavior>
    </i:Interaction.Behaviors>

    <Grid Height="250" Width="350" Background="Ivory">
        <Label Content="LoginDialogView" Height="29" HorizontalAlignment="Left" Name="label1" VerticalAlignment="Top" />
        <Label Content="UserName" Height="29" HorizontalAlignment="Left" Margin="22,70,0,0" VerticalAlignment="Top" />
        <Label Content="Password" Height="29" HorizontalAlignment="Left" Margin="22,112,0,0" VerticalAlignment="Top" />
        <TextBox Text="{Binding UserName}" Height="24" HorizontalAlignment="Left" Margin="96,72,0,0" VerticalAlignment="Top" Width="120" />
        <TextBox Text="{Binding Password}" Height="24" HorizontalAlignment="Left" Margin="96,114,0,0" VerticalAlignment="Top" Width="120" />
        <Button Content="Login" Command="{Binding LoginCommand}" Margin="61,157,189,39" />
        <Button Content="Cancel" Command="{Binding CancelCommand}" Margin="167,157,83,39" />
    </Grid>
</UserControl>

WindowStyleBehaviorは、そのStyleプロパティの値で、自身のコントロールを保持するWindowのStyleを上書きするビヘイビアです。このビヘイビアにより、ダイアログのWindowのStyleをViewの中から設定することができます。

これで、DialogBehaviorでのStyleの記述も不要となりますので、結果的にMainWindowのDialogBehaviorにはContentプロパティしか残らないことになります。

MainWindowのソースコードの抜粋（WindowStyleの移動）

    <i:Interaction.Behaviors>
        <mvvmdialogbehavor:DialogBehavior Content="{Binding Dialog}" />
    </i:Interaction.Behaviors>

Contentプロパティしか存在しないということは、MainWindowにはログインダイアログといった個別のダイアログに関する設定は含まれないということでもあります。これによってMainViewModelのDialogプロパティにセットするViewModelクラスの種類によって、ダイアログ種別を柔軟に切り替えることができるようになるのです。

実際のプロジェクトでは、この方法を全体的に使用していくのが良いでしょう。

□もっと実践的にMVVM Dialog Behaviorを使う　番外編　（WindowのStyleへのデータバインディング）

今までのWindowのStyleは静的に値を与えていましたが、これをダイアログのViewModelのプロパティとのデータバインディングによって動的に制御したい場合があるでしょう。その場合には以下のようにRelativeSourceを使用することで実現できます。

この例では、WindowのTitleプロパティに、ViewModelの WindowTitleプロパティをバインディングしています。

LoginDialogViewのソースコード（WindowのStyleにViewModelのプロパティをバインディング）

        <mvvmdialogbehavor:WindowStyleBehavior>
            <mvvmdialogbehavor:WindowStyleBehavior.Style>
                <Style TargetType="Window">
                    <Setter Property="Title" Value="{Binding Path=Content.WindowTitle, 
                        RelativeSource={RelativeSource Mode=Self}}"/>
                </Style>
            </mvvmdialogbehavor:WindowStyleBehavior.Style>
        </mvvmdialogbehavor:WindowStyleBehavior>

{RelativeSource Mode=Self}はダイアログのWindowインスタンスを表現します。そして、WindowのContentにはダイアログのViewModelが設定されていることを思い出してください。このため、Pathでは、Contentに続けてダイアログのViewModelのプロパティ名を記述することで、データバインドを行うことができます。

さて、既にもうほとんどのMVVM Dialog Behaviorの機能を使いながら紹介しました。あと２つだけ紹介していない機能があります。次にこれらについて説明していきます。

□その他のMVVM Dialog Behaviorの機能１　(IsModalプロパティ)

DialogBehaviorのIsModalプロパティは、モーダルにダイアログを表示するかをboolで指定します。デフォルトではモーダル（True）です。

MainWindowのソースコードの抜粋（IsModalを使用）

    <i:Interaction.Behaviors>
        <mvvmdialogbehavor:DialogBehavior Content="{Binding Dialog}" IsModal="False" />
    </i:Interaction.Behaviors>

□その他のMVVM Dialog Behaviorの機能２　(ContentTemplateプロパティ)

また、DialogBehaviorのContentTemplateプロパティは、ResourecesにDataTemplateを指定するよりも直接的にダイアログのViewを指定することができます。ContentTemplateプロパティのDataTemplateでは、マッピング対象の型に関わらず適用される型(DataTypeプロパティ)の指定が不要です。このため、ダイアログの見た目(View)を固定で決め打ちする場合に適しています。

MainWindowのソースコードの抜粋（LoginDialogView.xaml適用）

    <i:Interaction.Behaviors>
        <mvvmdialogbehavor:DialogBehavior Content="{Binding Dialog}" >
            
            <mvvmdialogbehavor:DialogBehavior.ContentTemplate>
                <DataTemplate>
                    <local:LoginDialogView />
                </DataTemplate>
            </mvvmdialogbehavor:DialogBehavior.ContentTemplate>


        </mvvmdialogbehavor:DialogBehavior>
    </i:Interaction.Behaviors>

以上で、MVVM Dialog Behaviorの機能の説明はひととおり終了です。後はいくつか補足をしてMVVM Dialog Behaviorの説明を終了としましょう。

□[補足]ラベルやボタンでのコンテンツの表示と、ダイアログ表示とで、同じプログラミング体験を提供します

DataTemplateにあまりなじみがない方には、DialogBehaviorビヘイビアのこの使用方法はちょっと難しかったかもしれません。しかし、これはラベルやボタン（ContentControlを継承している）のでのコンテンツ表示と同じプログラミング体験を提供するという目的によるものです。

実は、DialogBehaviorビヘイビアをContentControl置き換えて（＋さらにほんの少しだけ修正する必要がありますが。）も、そのまま動作します。

この場合、メインウィンドウのOpenDialogボタンを押すと、なんと以下のようにメインウィンドウ内にログインダイアログが出現します。もちろんLoginボタンを押すと元通りに消えるというダイアログらしさもそのままです。

メインウィンドウ（ContentControl版）

このContentControlによるコンテンツの表示は、MVVMではよく知られたテクニックの一つです。（知らなかった方はこの機会に是非慣れ親しんでください。）

このように、MVVM Dialog Behaviorでは、ラベルやボタン（ContentControlを継承している）のコンテンツ表示と、ダイアログ表示とが同様のプログラミング体験となるように、そのインタフェースが設計されているのです。

ちなみに、以下のようにMainWindowのソースコードを修正すると上記ことが実現できます。

MainWindowのソースコード（ContentControl版）

<Window x:Class="MvvmDialogBehaviorSample.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:MvvmDialogBehaviorSample"
        xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
        xmlns:cmd="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras.WPF4"
        xmlns:mvvmdialogbehavor="clr-namespace:MvvmDialogBehavior;assembly=MvvmDialogBehavior"
        Title="MainWindow" Height="275" Width="375" Background="Azure">
    <Window.DataContext>
        <local:MainViewModel />
    </Window.DataContext>

    <Grid>
        <ContentControl Content="{Binding Dialog}">
            <ContentControl.Resources>
                <DataTemplate DataType="{x:Type local:LoginDialogViewModel}" >
                    <Grid Height="250" Width="350" Background="Ivory">
                        <Label Content="LoginDialogView" Height="29" HorizontalAlignment="Left" Name="label1" VerticalAlignment="Top" />
                        <Label Content="UserName" Height="29" HorizontalAlignment="Left" Margin="22,70,0,0" VerticalAlignment="Top" />
                        <Label Content="Password" Height="29" HorizontalAlignment="Left" Margin="22,112,0,0" VerticalAlignment="Top" />
                        <TextBox Text="{Binding UserName}" Height="24" HorizontalAlignment="Left" Margin="96,72,0,0" VerticalAlignment="Top" Width="120" />
                        <TextBox Text="{Binding Password}" Height="24" HorizontalAlignment="Left" Margin="96,114,0,0" VerticalAlignment="Top" Width="120" />
                        <Button Content="Login" Command="{Binding LoginCommand}" Margin="61,157,189,39" />
                        <Button Content="Cancel" Command="{Binding CancelCommand}" Margin="167,157,83,39" />
                    </Grid>
                </DataTemplate>
            </ContentControl.Resources>
        </ContentControl>

        <Button Content="Open Dialog" Command="{Binding OpenDialogCommand}" Height="49" HorizontalAlignment="Left" Margin="88,83,0,0" Name="button1" VerticalAlignment="Top" Width="160" />
    </Grid>
</Window>

□[補足]ダイアログの閉じるボタンを押されたらどうなる？

ダイアログには、何も指定しないと右上に閉じるボタンが表示されます。このボタンを押した場合、DialogBehaviorはどのような振る舞いをするのでしょうか？

実は、ダイアログが閉じられるとDialogBehaviorのContentプロパティはNullに設定されます。このContentプロパティにダイアログViewModelのプロパティがバインドされるでしょうから、バインディング機能により、ダイアログViewModelへプロパティも同時にNullに設定されることになります。

実はこの仕組みによって、ダイアログViewModelインスタンスが存在するかNullかでダイアログの表示中かどうかが判断できるように、常にViewModel側の状態に同期されることになるのです。

なお、Alt+F4などのウィンドウを閉じるショートカットキーが押された場合でも同様の動きをします。

□[補足]メッセンジャーによるダイアログ表示との使い分け

メッセンジャーによるダイアログ表示はMVVMに反するところがあると述べましたが、実際のところ、OKやCancelボタンがあるだけのような単純なメッセージボックスや、ファイル選択のダイアログなどであれば、そもそもViewModelで制御したいとも思わないかもしれません。

そうした場合には、 MVVM Dialog Behaviorを使用する必要はなく、何れかのMVVMフレームワークが提供するメッセージボックスのためのメッセンジャー（およびメッセージやアクション）を使用するのも良いでしょう。

しかし、ある程度の複雑なプレゼンテーションロジックを持ったダイアログを表示する場合や、ダイアログ表示中かどうかをViewModel内で判断してその表示を制御したいなどの場合、あるいはダイアログのテーマを自由にデザインしたい場合には、このMVVM Dialog Behaviorの使用を検討する価値があります。

プロジェクト要件に応じて使い分けるようにしてください。

□まとめ

これで、MVVMでメッセンジャーなしにダイアログ表示をシンプルに実現させるMVVM Dialog Behaviorライブラリのご紹介は終了です。

メッセンジャーによるダイアログ表示に疑問を持ったらこのライブラリを使ってみることを検討してください。このライブラリが少しでも皆様のMVVMライフの足しになれば幸いです。

長文お疲れ様でした。

以上。

MVVMでメッセンジャーなしに画面遷移を実現する- 画面遷移を画面状態としてモデル化する

2011-12-05T21:26:00.001+09:00

□導入

今回のブログでは、「MVVMでメッセンジャーなしに画面遷移を実現する - 画面遷移を画面状態としてモデル化する」と題しまして、メッセンジャーなしに画面遷移を実現する方法のひとつをご紹介します。

MVVMをご提案すると「画面遷移とダイアログ表示はどうするのか？」と、多くの技術者が聞いてきます。どうやら自分でも調べてこのあたりがMVVMの鬼門だと感じ取るようです。

「どうやら画面遷移とダイアログ表示のためには、メッセンジャーを使うらしい。」　→　「調べたけどなんだかメッセンジャーが難しい、分からん。］　→　「そもそもこんなことまでして、どうしてMVVMを使わなければならないんだ？」となります。

こうなると、画面遷移やダイアログ表示がMVVMでの問題であることを前提として、MVVMのメリット面を説明していく必要があり、このマイナスからの説明で私はいつも息切れしてしまいます。どうやら、MVVM入門者にはメッセンジャーはハードルが高すぎるようです（そして私自身メッセンジャーをあまりよく思っていません :p ）。MVVMを保ちつつも、シンプルに画面遷移やダイアログ表示を実現する代替の方法が求められていると感じます。

ダイアログ表示については、以前の私のブログで「MVVMでダイアログ表示のためにメッセンジャーを使用するのはおかしいのでは？」と題して、実績の薄い方法ながらご説明しましたので、今回は画面遷移についてご説明します。

実はここでご紹介する画面遷移の方法は、世の中的にはメジャーなはずなのですが、なぜか日本語のコンテンツを探してもなかなか見つけることができなかった方法です。なお、DataTemplateのDataTypeを使用しますので、Silverlightユーザはご注意ください。

□サンプル画面の画面仕様

サンプルとして以下のような単純な画面を考えましょう。

Aページの画面

Bページの画面

メイン画面があり、そこにはページを切り替えるトグルボタンを持っています（ちょっとわかりにくいですが、ウィンドウの上部にある「TogglePageCommand」と表示された細長いボタンがトグルボタンです）。そして、トグルボタンを押下することでＡ→ＢそしてＢ→Ａへのページ遷移を行うというものです。

なお、Ａページにはテキストボックスを持つことにしましょう。

□ViewModelのクラス図を作成する

ViewModelはクラス図作ってちゃんとモデリングすることを推している私の立場もあるので、次に画面遷移をViewModelのクラス図としてモデル化してみます。

MainViewModelをメインウィンドウ用のViewModelとし、APageViewModelおよびBPageViewModelをそれぞれAページ用とBページ用のViewModelとします。

MainViewModelが保持しているCurrentPage関連で現在のページを表現しています。これはViewModelBaseを指していますが、具体的にはそのサブクラスであるAPageViewModelインスタンスを保持している時にはAページが表示され、BPageViewModelインスタンスを保持している時にはBページが表示されることとします。

つまり、このCurrentPage関連に保持するViewModelインスタンスを切り替えることで画面遷移を発生させることができるということです。このようにViewModelの状態を変更することで画面を制御できるのがMVVMの醍醐味ですね。

また、MainViewModelのAPage関連とBPage関連には、それぞれＡページとBページのためのViewModelインスタンスをあらかじめ作成して保持しておくものとします。

□ViewModelの実装

ViewModelの設計も終わったので、ViewModelの実装を以下に示します。なお、ViewModelBaseとコマンドのために、MVVM Light Toolkitを使用した実装になっていますが、その他のライブラリを使用している方は適宜読み替えてください。

まずは、MainViewModelのコードです。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using GalaSoft.MvvmLight;
using System.Windows.Input;
using GalaSoft.MvvmLight.Command;

namespace MvvmTransition.ViewModel
{
    public class MainViewModel:ViewModelBase
    {
        public MainViewModel()
        {
            APage = new APageViewModel();
            BPage = new BPageViewModel();
            CurrentPage = APage; 
        }

        private ViewModelBase _CurrentPage;
        public ViewModelBase CurrentPage
        {
            get { return _CurrentPage; }
            set
            {
                if (_CurrentPage != value)
                {
                    _CurrentPage = value;
                    RaisePropertyChanged("CurrentPage");
                }
            }
        }

        private APageViewModel _APage;
        public APageViewModel APage
        {
            get { return _APage; }
            set
            {
                if (_APage != value)
                {
                    _APage = value;
                    RaisePropertyChanged("APage");
                }
            }
        }

        private BPageViewModel _BPage;
        public BPageViewModel BPage
        {
            get { return _BPage; }
            set
            {
                if (_BPage != value)
                {
                    _BPage = value;
                    RaisePropertyChanged("BPage");
                }
            }
        }

        private ICommand _TogglePageCommand;
        public ICommand TogglePageCommand
        {
            get { 
                if (_TogglePageCommand == null)
                {
                    _TogglePageCommand = new RelayCommand(TogglePage);
                }

                return _TogglePageCommand;
            }
        }

        private void TogglePage()
        {
            if (CurrentPage == APage) // AページだったらBページに切り替え
            {
                CurrentPage = BPage;
            }
            else if (CurrentPage == BPage) // BページだったらAページに切り替え
            {
                CurrentPage = APage;
            }
        }
    }
}

以上で、MainViewModelのコードですが、当然ながらクラス図の通りですね。なお、TogglePage（）にトグルボタンを押下した際に実行されるコードが記述されていますが、CurrentPageのViewModelのインスタンスをA用とB用で切り替えているだけです。

次に、Ａページ用のViewModelとBページ用のViewModelです。

ＡページのViewModel

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using GalaSoft.MvvmLight;

namespace MvvmTransition.ViewModel
{
    public class APageViewModel:ViewModelBase
    {
        private string _AText;
        public string AText
        {
            get { return _AText; }
            set
            {
                if (_AText != value)
                {
                    _AText = value;
                    RaisePropertyChanged("AText");
                }
            }
        }
    }
}

BページのViewModel

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using GalaSoft.MvvmLight;

namespace MvvmTransition.ViewModel
{
    public class BPageViewModel:ViewModelBase
    {
    }
}

サンプルでは単純すぎて、Ａページ用のViewModelとBページ用のViewModelを説明する必要もないでしょう。実際の開発ではAページとBページは大きく異なる画面となるでしょうから、それぞれのページに適したプロパティを追加することになります。

これでViewModelの実装は終わりました。簡単ですね。

□Viewの実装

次にViewの実装を説明します。まずは、単純なAページ用のViewとBページ用のViewです。

AページのViewのコード

<UserControl x:Class="MvvmTransition.APageView"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:localvm="clr-namespace:MvvmTransition.ViewModel"
        xmlns:localview="clr-namespace:MvvmTransition" Background="Red">
    <StackPanel>
        <Label Content="A Page"/>
        <TextBox Text="{Binding AText}" Width="150"/>
    </StackPanel>
</UserControl>

BページのViewのコード

<UserControl x:Class="MvvmTransition.BPageView"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:localvm="clr-namespace:MvvmTransition.ViewModel"
        xmlns:localview="clr-namespace:MvvmTransition"  Background="Blue">
    <StackPanel>
        <Label Content="B Page"/>
    </StackPanel>
</UserControl>

これらのViewは単純なので説明も不要でしょう。

次はメイン画面のViewのコードです。ポイントは2つあります。1つ目は、AページとBページのViewとViewModelのマッピングを実施している点、そして２つ目は、CurrentPageのViewModelを使用して現在の画面を表示を実現している点です。

メイン画面のViewのコード

<Window
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:localvm="clr-namespace:MvvmTransition.ViewModel"
        xmlns:localview="clr-namespace:MvvmTransition"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

        mc:Ignorable="d" x:Class="MvvmTransition.MainWindow"
        Title="MainWindow" Height="350" Width="525">

     <!-- AページとBページのViewとViewModelのマッピング -->
    <Window.Resources>
        <DataTemplate DataType="{x:Type localvm:APageViewModel}">
            <localview:APageView />
        </DataTemplate>
        <DataTemplate DataType="{x:Type localvm:BPageViewModel}">
            <localview:BPageView />
        </DataTemplate>
    </Window.Resources>
    
    <Window.DataContext>
        <localvm:MainViewModel/>
    </Window.DataContext>

    <DockPanel LastChildFill="True" >
        <Button DockPanel.Dock="Top" Content="TogglePageCommand" Command="{Binding TogglePageCommand}"/>
        <!-- CurrentPageのViewModelを使用して現在の画面を表示 -->
        <ContentControl DockPanel.Dock="Bottom" Content="{Binding CurrentPage}" />

    </DockPanel>
</Window>

「AページとBページのViewとViewModelのマッピング」では、DataTemplateの機能を利用しています。このDataTemplateを使用したViewとViewModelのマッピングは、WPFを使用したMVVMでは一般的な方法の１つです。DataTempleteの機能により、ViewModelというある種のデータを画面に表示する際に、自動的に対応するViewが適用されます。そしてこの場合、ViewとViewModel間のDataContextの設定まで自動的に行われます。これは私がMVVMで開発している時には、最もよく使用するViewとViewModelのマッピング方法です。

ちなみに私のViewとViewModelのマッピングの基本的なスタンスとしては、メイン画面などの頂点のウィンドウには、

<Window.DataContext>
<localvm:MainViewModel />
</Window.DataContext>

のようにXaml内でDataCotextを指定したり、コードビハインドでViewModelをViewのDataContextに設定するようにしています。そして、頂点のウィンドウ以外の場所では、（なるべく）このDataTemplateを用いたViewとViewModelのマッピングを行うようにしています。

なお、DataTempleteでのマッピングは、システムに対して１つだけグローバルな定義があれば良いので、ResourceDictionaryの別出しのXamlファイルとして定義して、そのファイルをApp.xamlにマージすると、さらにメイン画面のViewをシンプルに保つことができます。

次に、「CurrentPageのViewModelを使用して現在の画面を表示」では、ContentControlのContentプロパティに、MainViewModelのCurrentPageプロパティをバインディングしています。

ContentにViewModelの値を直接指定していますが、この場合には上記のDataTempleが適用されますので、AページのViewModelが含まれている場合にはAページのViewとなりますし、BページのViewModelが含まれている場合にはBページのViewとなります。当然、ViewModelが変更されれば内容が切り替わりますので、これによって画面遷移が実現できるというわけです。

ちなみに、このContentContorlを利用してViewModelをViewに変換するというのはMVVMではよく使うテクニックの一つです。また、同様にItemsControlのItemsSourceではViewModelのリストを取り扱うこともできますのでこちらも覚えておくと良いと思います。

□まとめ

これで、MVVMでメッセンジャーなしに画面遷移をシンプルに実現する方法のご紹介は終了です。

今回ご紹介した画面遷移の方法は、シンプルですしViewModel内でしっかりと画面遷移を制御できるため個人的にお勧めです。

また、ViewModelはこのままの構造としておいて、View側でCurrentPageを確認しながらVisibilityやZIndexを変更するような方法も（ちょっとがんばる必要がありますが）ありえるかと思います。

ちょっと話がそれますが、実はこのアプリでは、画面遷移してＡページから再びＡページへ戻ってきても、テキストの内容が保持されたままになっています。もしも画面遷移時にデータを削除したいような場合には、トグルボタン押下時に毎度ViewModelをnewしてしまうようにコードを修正することで実現可能です。このようにViewModelはセッションのような役割を持つことができるのも特徴です。

一方で、メッセンジャーを使用して画面遷移を行う方法はフレームワークに多く、フレームワーク側で、ViewModelのライフサイクル管理やセッション管理のようなことをやってくれるようなものも存在しますので、どのような画面遷移の方法を採用するかは、やはりプロジェクトの要件に応じて検討する必要があります。

今回は、画面遷移をシンプルに実現する方法をご説明しました。メッセンジャーによってMVVMの食わず嫌いとなることが多少なり緩和され、少しでも多くの方にMVVMの興味をもっていただければ幸いです。

以上。

ViewModel設計の原則　その３

2011-12-05T02:34:00.000+09:00

□導入

今回のブログでは、３番目の原則として「ViewModel設計を画面設計に位置づけ積極的に設計すること」を説明します。

順を追って説明するために、まずここでの用語の定義として、画面仕様と画面設計の言葉の使い分けについて説明します。その上で、ViewModelの画面設計について説明していきます。

なお、ここでの説明がどのプロジェクトにも適用可能な正しい内容であるかは分からないことをあらかじめご承知おきください。ここでの内容をそれぞれのプロジェクトで使用するのはもちろん構いませんが、すべて自己責任でお願いします。

□画面仕様と画面設計の言葉の使い分け

今後の説明を円滑にするため、ここでの「画面仕様」と「画面設計」という言葉を簡単ながら定義しておきます。

ここでの「画面仕様」というのは「どのような画面を作成するのか」という画面のWhatを定義するものとします。具体的には、どのような画面と画面遷移が存在し、どのような画面レイアウトで、どのような画面の項目があり、それらの画面項目は数字なのか文字列なのか、必須なのかあるいは上限値や下限値といったものを定義します。

一方、ここでの「画面設計」というのは「どのように画面を作成するのか」という画面のHowを定義するものとします。具体的には後で説明するように、ViewModelのクラス図などがこれにあたります。

なお、他ではここでの画面仕様と画面設計という言葉の使い分けは行われていないことにご注意ください。

□みんな画面設計ってやってる？

「画面仕様書」や「画面定義書」や「画面設計書」という言葉は世の中でもよく使用されている言葉です。しかし、実際のところ、これらはあまり明確に使い分けられていないように思います（少なくとも私の周りでは）。これらは私の知る限りでは、先ほど言葉として定義した「画面仕様」を定義するためのドキュメントです。

一方、先ほど言葉として定義した「画面設計」を定義するためのドキュメントは、通常は作成されません。強いて言うなら、クラス設計書などが一番近いでしょうか。しかし、これもプロジェクトの多くでは共通部分などの重要な部分に絞って作成される程度であり、またアプリケーションレベルの画面に特化して作成するとなるとさらに少なくなります。

このように「画面設計」のためのドキュメントが作成されないてこなかったのは、まずそもそも複雑でリッチな画面を作成することが少なかったということがあります。ゲームなど一部の業界を除くと、リッチな画面が求められるようになったのは比較的最近になってのことです。しかし、モバイル系やWeb系のアプリを中心としてリッチな画面を作成する必要性は増しているので、それに応じて画面設計が必要とされるケースも増えていくでしょう。

そして、この画面設計を目的としてMVVMパターン（より正確にはPresentation Modelパターン）を使用することができます。

□画面設計したいならMVVM

MVC などの他の画面アーキテクチャの場合、レイヤの分けが、画面自体の抽象ではなく、画面を構成する機能の分担となっています。このため、VやCといった単位であっても個別にみてみれば実装レベルのものしかでてきません。無理に画面設計らしいものを作ろうとしても、むしろ画面を実装しながら作成したほうが良いようなXML Documentationと大差ないものになるのが関の山でしょう。

しかし、MVVM（より正確にはPresentation Model）のViewModelは、画面自体を抽象化した画面モデルです。また、画面仕様が存在すれば、画面の実装に先だって作成することができます。こうしたことからViewModelのクラス図は画面設計として扱うことができるのです。

この画面設計を行えるという利点は、ある種のプロジェクトではMVVMを採用する強い動機となり得えます。

□Eclipseプラグイン開発をしていた時の経験

以前私は、Eclipseのプラグイン開発を行っていましたことがあります。画面仕様もリッチで、かつ実装もそれなりに大きなものでした。画面のための共通ライブラリを作成して、そこではドキュメント化を行ったものの、それを使用して作成される個々の画面では、画面設計らしいものは何もなくただ巨大なコードの塊があるのみでした。

画面の共通ライブラリによって実装をガイドとする方針でしたが、それでも画面を実装した人に任される部分も多く、画面実装が開始されてしまうとそこから先はブラックボックスとなり、他の人は手を出すのが難しい状況となりました。開発から保守のフェーズに移行するタイミングでソフトウェアを引継ぎきましたが、お世辞にも引き継いだといえるようなものでありませんでした。

こうしたことはリッチな画面だから仕方がないのだと当時は思ったものですが、現在では「MVVMを使っていれば」と思うことがあります。MVVMであれば、画面のための共通フレームワークの構成も異なるものであっただろうこと、ViewModelのクラス図を使ってレビューもかけて品質と実装の均一化を担保できたであろうこと、画面開発のスキルの展開も容易であっただろうことを想像します。

MVVMでの、ViewModel設計をしっかりと行うことで、ソフトウェア品質と保守性の向上に役立ちます。

□Eclipseプラグイン開発はモデリングを中心としている

ちなみに、MVVMはWPFやSilverlightの技術ではありますが、MVVMがベースとしているはPresentationModelや Application Modelと呼ばれるパターンです。私がEclipseプラグインの開発していていたころにはまだ存在しなかったのですが、実は次世代のEclipseにもこれらのパターンが導入された「Modeled UI」と呼ばれる技術が存在します。

実はEclipseのプラグイン開発の世界は、そもそもモデリングがとても重視されている世界であり、モデル化のためのライブラリがとても充実しています。私がプラグインを開発していた当時はMVVMのような汎用的な画面自体のモデリングは（たぶん）なかったものの、UMLツールのようなグラフィカルなツールを作成するライブラリや、その他多くのライブラリがモデルをプラグインして拡張されることを当たり前としていました。そして、Modeled UIと呼ばれる技術も、比較的モデリング色が強い技術となっています。Eclipseプラグイン機構自体が巨大なDSLとメタモデルをプラグインしていくための基盤のようなものであり、そしてＵＩ自体も複雑になりがちなので、当然のようにモデリングが中心となっているのです。

このときの私の経験はMVVMでの開発にも生かされました。

WPF/Silverlightのデータバインドやその他の技術は、EclipseやJavaが持つ技術に比べるととても強力です。使いこなせばMVVMを強力にサポートしてくれます。しかし私が初めてMVVMを勉強したとき、足元をすくわれたのもこれらの技術でした。たくさんの技術にばかり目を奪われて方向性を見失い、結局のところどうしてよいのか分からず途方に暮れてしまったのです。

この時に、Eclipseプラグインでのモデリングの経験が役に立ちました。ViewModel（Presentation Model)をしっかりとモデル化する道をとることで、これら技術をどこで使うべきなのかをガイドしてくれるようになったのです。

そして、ViewModelのモデリングは、Eclipseのような手厚いモデルのためのサポートがなくてもあまり問題にならないこともこのとき分かりました。（ただし、何かViewModelを生成するような仕組みがあったほうが便利ではあります。自分のプロジェクトでもViewModelの自動生成の機構は開発しています。）

ViewModelのモデリングなしでは今でもMVVMで途方に暮れていたことは容易に想像できます。モデリングによるUIの開発はEclipseでの専売特許ではありません。WPF/Silverlightはモデリングのための技術が薄いですが、それでも全体的にはMVVMのための手厚い技術が存在しており、むしろEclipseよりも適しています。

□[原則３]ViewModel設計を画面設計に位置づけ積極的に設計すること

MVVMは画面設計を行うことができるUIアーキテクチャです。プロジェクトの性質によっては、採用の大きな動機となり得ます。ViewModel設計をしっかりと行うことで、ソフトウェア品質と保守性の向上に役立ちます。

ViewModelをしっかりとモデリングすることで、MVVMの技術に振り回されず、これらを支配下においてください。MVVMの本質は画面のモデリングであり、そしてViewModelの設計であるといっても過言ではありません。

[原則３]ViewModel設計を画面設計に位置づけ積極的に設計すること

これで、今回のブログは終了です。長文お疲れ様でした。
これまでの説明ではViewModel設計の位置づけ的なお話が多かったと思いますが、次回以降では、よりViewModelの設計方法について説明していきます。技術者にとっては次回以降の方が読んで楽しいかもしれませんね。ご期待ください。

以上。

ViewModel設計の原則　その２

2011-11-22T23:44:00.010+09:00

□導入

今回のブログでは、2番目の原則として「画面定義後、Viewの実装の前にViewModelの（簡易）設計を行うこと」を説明します。順を追って説明するために、まずViewModel設計の優れた例としてMSDN Manazineのサンプルを見てみます。これをベースとして、「画面定義後にViewModelの（簡易）設計を行う必要があること」を説明します。その後、「ViewModelの設計を行った後にViewの実装を行う必要があること」を説明します。

なお、ここでの説明がどのプロジェクトにも適用可能な正しい内容であるかは分からないことをあらかじめご承知おきください。ここでの内容をそれぞれのプロジェクトで使用するのはもちろん構いませんが、すべて自己責任でお願いします。

□ViewModel設計の例

それでは早速、良いMVVMの設計例として、MSDN Manazineのサンプルを見てみましょう。ここで紹介されているのは、顧客管理のためのサンプルであり、以下のような画面です。

「Model-View-ViewModel デザインパターンによる WPF アプリケーション」
http://msdn.microsoft.com/ja-jp/magazine/dd419663.aspx
（このMSDN Magazineのサンプルコードは、MVVMを学ぶ上でとても参考になりますので、MVVMを初めて学ぶ際には是非ソースコードまでご覧ください。）

顧客リストをワークスペースに表示

新規顧客作成用画面をワークスペースに表示

メイン画面の中が左右2つに分かれています。右側には顧客情報の参照や編集のためのワークスペースが存在します。これはVisual Studioのエディタ領域をイメージすると分かりやすいかと思います。一方、左側には顧客リストを表示するためのリンクと、新規顧客作成用画面を表示するためのリンクが存在しています。これらのリンクを押下することでワークスペースに顧客リスト、あるいは新規顧客作成画面がタブとして表示されます。

この画面のViewModelの構造をクラス図で見てみます。（MSDN Manazineにもクラス図はありますが、ViewModelの全体の構造が分かりにくいため、サンプルのソースコードから改めて私の方でクラス図を書き起こしました。）

ViewModelBaseがすべてのViewModelの共通親クラスとして存在しています。

WorkspaceViewModelはCloseCommandプロパティを持ち、クローズ可能なViewModelとしての意味合いを持っています。それらのサブクラスとして、新規顧客作成のためのCustomerViewModelと、顧客リストのためのAllCustomerViewModelと、メイン画面のためのMainWindowViewModelがあります。
（なお、個人的にはWorkspaceViewModelのサブクラスは、ワークスペースのタブに含まれるものだけにして、MainWindowViewModelを含めないほうが良かったのでは、と思います）

メイン画面を表すMainWindowViewModelを見てみると、Workspaces関連に自身がタブとして持つWorkspaceViewModelのリストを保持しています。また、Commands関連に顧客リストを表示するためのリンクと、新規顧客作成用画面を表示するためのリンクを表現するCommnadViewModelをリストとして保持しています。

このように継承関係やコンポジション関連により、ViewModel全体がしっかりとした構造を持ち、連携が行われていることが読み取れます。

これは比較的単純な画面の例ではありますが、複雑な画面になれば、構造もそれに応じて大きくなっていきます。

□画面構造にViewModel構造は依存する

このサンプルプログラムで確認しておきたいのが、画面構造とViewModel構造の対応関係です。メイン画面の左側のリンク群と右側のワークスペースのタブ群の構成に対応して、MainWindowViewModelにリンク群を表現するCommands関連と、ワークスペース群を表現するWorkspaces関連が存在します。

このように画面構造（画面の概念的な構造）とViewModelの構造とが対応づいているのは偶然ではありません。これは明に暗に画面のモデリングの結果としてViewModelが定義されているからです。そしてViewModel設計のインプットとして画面仕様が必要であり、またViewModel構造は画面仕様（画面構造）に依存するということでもあります。

□ViewModel設計のための画面仕様は、まずはホワイトボードレベルで構わない

ViewModel設計に先だって画面仕様が決まっていなければならないことを説明しました。

このViewModel設計のための画面仕様は、まずはホワイトボードに記述する大雑把なレベルのもので構いません（もちろん詳細に決まっていて困るものでもありませんが）。これは、ViewModelは段階的に詳細化していけば良いためです。

ドメインモデルの設計でも、細かな振る舞いはまずはおいておいて、大雑把な構造を洗い出すことを優先することが多いのではないでしょうか。同様にViewModelの設計でも、まずは大雑把な構造を洗い出すことを優先したほうがうまくいきやすいように思います。実際のところ、よほど簡単な画面でもない限りViewModel設計をはじめから完璧に仕上げるのは不可能です。

特にViewModelでは、画面のための細かな属性や操作が多くなり、またドメインモデルよりも実装寄りの設計となる傾向があります。このため、ViewModel設計で細部に注目してしまうと全体像がおろそかになって袋小路に入り込みやすいのです。属性や操作の細かな洗い出しはまずはおいていて、箱と線による構造の洗い出しに注力するようにしてください。細かな属性や操作はViewModelを実装しながら洗い出して行っても良いと思います。

画面仕様もViewModelもそれぞれ段階的に肉付けしていけば良いのです。

□[余談]WPFからSilverlightへの移行は容易か

ところで話が逸れますが、MVVMで開発した場合、WPFからSilverlightへの移行のように、UIシステムの変更が可能だといわれています。これは、WPFもSilverlightもViewに属するので、UIシステムの変更でViewは変わっても、ViewModelはそのまま再利用可能であるということを指しており、実際その通りではあるのですが注意が必要です。というのもViewModelの構造は画面仕様に依存します。このため、 ViewModelを変更せずに済むのは、画面仕様を変更しない（あるいはほとんど変更しない）で移行した場合の話だということです。

もしも、WPFからSilverlightへの移行が、PC画面での使用からモバイルでの使用を意図したものであるとすると、画面サイズの制約により画面仕様が根底から異なるものになるでしょう。こうした場合には、ViewModelを大きく修正する必要があり、流用可能なViewModelのコードはおそらく半分もありません。むしろPC画面用とモバイル用のViewModelの無理な共通化は、ViewModelを複雑怪奇な構成にしてしまう可能性があります。そういったことをするよりはViewModelを最小限の共通化にとどめてイチから別途開発ししつつ、共通化はModelのレイヤで目指したほうが良いことも多いと思います。

個人的には、MVVMによるUIシステムの変更容易性のメリットは、少し過大評価されているように思います。

私は以前、ViewModelによってWPFからSilverlightなどへのUIシステムの変更に強いことから、「ViewModelは画面仕様の変更にも強くなければならず、画面仕様から独立した存在としなければならないのではないか」と勘違いしていたことがあります。しかし、このような勘違いは、ViewModelの存在を、どのような画面にでも使用できるような、単なるModelラッパーにまで責務の範囲を狭め、有効な ViewModelを設計できない原因となります。変な表現ではありますが「むしろ安心してViewModelを画面仕様に依存させてください」。

なお、ViewModelは画面仕様に依存するのですが、ViewModelがあることで画面の変更容易性が下がるという意味ではないことに注意してください。実際のところ、ViewModelは画面のモデルであり、抽象化が行われる分だけ画面の修正には強くなります。しかしそうはいっても、画面構造の大きな変化には、ViewModelであっても大きな影響を受けるということです。

（なお、ViewModelにも画面仕様よりのViewModelと、モデルよりのViewModelがあり、このため画面仕様の変更のおよぶViewModelと、変更の及ばない ViewModelがあります。この辺りについては、機会があればご説明したいと思います。）

□ViewModelを検討してから、Viewを実装するという流れを守る

前回のブログの「期限が迫っている項目を赤く強調表示したい」というストーリーにて、ViewModelによる抽象化された画面に対するプログラミングの実現と、ViewModelとViewの主従関係について説明しました。このように画面の制御はViewModelに対して行われ、Viewがそれを実現するという関係があります。

コンポーネントに例えるとViewModelがインタフェースであり、Viewはその実装といっても良いでしょう（※1）。こうして考えると、手順としてインタフェースであるViewModelを検討してから、実装であるViewを検討するというのはごく自然な流れです。この検討の流れは必ず守るようにしてください。

この流れを守ることでViewが実現すべき目標をViewModelが与えてくれるようになります。Viewは、ViewModelが意図する仕様に向けて実装すれば良いのです。明確な目標が存在することで高い生産性を保ちつつViewのプログラミングをすることが可能です。

一方、View側から着手してViewModelを作成していくスタイルの開発を進めていくと、ViewとViewModelの境界を探り探りプログラミングすることとなり、自信を持ってプログラミングすることができません。作成されるViewModelも、他のViewModelと連携が行われない孤島のようなViewModelとなりやすく、結果としてViewModelとしての力を発揮することができません。こうなってしまうとViewModelを導入せずににコードビハインドで実現したほうが、むしろ手数が少なく幾分かマシという状況にさえなってしまいます。

こうしたView側から着手してしまう状況は、幸か不幸かVisual StudioやExpression Blendで画面仕様の定義を兼ねて簡単にXamlでスケッチをかけことにより、比較的容易に発生します。スケッチとして作成したXamlをそのままViewへと転用することで、ViewModelの設計がなおざりになってしまうのです。こうしたスケッチは、そのままMVVMのViewとして使用するのではなく、 ViewModelの設計を行ったうえで、使用できる部分だけ利用する程度に留めることをお勧めします。基本的にはそうしたスケッチはすべて捨てるぐらいの覚悟で丁度良いと思います。

ViewModelを検討してから、Viewを実装するという流れを守るようにしてください。

※１：一般的なインタフェースと違って、ViewModelは単体として意味を持つものではありません。複数のViewModelインスタンスが、オブジェクトツリー（あるいはグラフ）となり、その構成全体として画面の状態を表現します。こうした点は異なるものの、ViewModelとViewには主従関係があり、イメージとしてViewModelがインタフェース、Viewはその実装と考えても問題ないと思います。

□[原則２]画面定義後、Viewの実装の前にViewModelの（簡易）設計を行うこと

今ままでの説明が、画面仕様の定義後にViewModel設計を行うこと、またViewModel設計の後にViewの実装を行うべきであるということの解説となります。

Viewを実現するWPF/Silverlightや、MVVMフレームワークなど、これら自体が大きな技術ですので、圧倒されてしまって結果的にViewを開発の中心に据えてしまう気持ちも分からないではありません。しかし、これらはあくまで実現手段にすぎません。

そうではなくViewModelを中心に据えるようにしてください、、、と、なんと実はこちらも間違いです。

「本当の意味で中心に据えるべきはユーザであり、そこから段階的に詳細化しながら導かれていくのが、システム仕様であり、機能仕様であり、画面仕様であり、画面設計であり、ViewModelであり、Viewの実装なのです」。むしろこちらの方がソフトウェア開発全体を捉えたより正しい原則といえるかもしれません。

ViewModelさえもあくまで画面の実現手段にすぎません。私自身よく忘れてしまうことですが、技術に振り回されずに、より大きな目的の中に技術を位置づけることが大切です。

[原則２]画面定義後、Viewの実装の前にViewModelの（簡易）設計を行うこと

これで、今回のブログは終了です。長文お疲れ様でした。

以上。

ViewModel設計の原則　その１

2011-10-27T19:46:00.017+09:00

□導入

MVVMの知名度は十分に高まっているものの、MVVMでの開発はまだまだしきいが高いと感じる方が多いのではないかと思います。確かに、MVVMで開発するためのライブラリやフレームワークが出揃い始めており、それらの技術について説明したコンテンツも充実しつつあるように思います。しかし、これらの技術をどう使って設計していけばよいのかはどのコンテンツにもあまり語られていません。特にMVVMの肝であるはずのView Modelの設計をどうしたらよいのかについて説明しているコンテンツがなく、各技術者に任されてしまっています。

私自身、模索を繰り返しながら何とかViewModelの設計をやっているのが実態で、まだまだ不明な点が多くあります。しかし、今まで私がMVVMによる開発を行ってきたなかで得たものを、「View Model設計のための原則」というテーマで、何回かに分けてご紹介したいと思います。いくらかでもMVVMによる開発の参考になれば幸いです。

なお、ここでの説明がどのプロジェクトにも適用可能な正しい内容であるかは分からないことをあらかじめご承知おきください。ここでの内容をそれぞれのプロジェクトで使用するのはもちろん構いませんが、すべて自己責任でお願いします。

□MVVMパターンとは

早速ですが、そもそもMVVMパターンとは何かというと「Model-View-ViewModelパターン」のことです。

MVVMでのModelとは、ビジネスロジックとデータを表現し、一般にドメインモデルと呼ばれたりする"モデル"です。データベースを使用した場合にはORマッピングされるエンティティや、サービスとして実装される部分です。MVVMパターンはGUIのためのパターンであるため、本ブログではあまり説明しませんが、このモデル自体、システムの中でとても大きな位置を占めるので注意が必要です。

MVVMでのViewは、画面コントロール、画面レイアウト、フォント、色彩、アニメーション、ＵＩロジックを表現します。通常はXAMLで実装し、可能な限りコードビハインドは使用しません。これは、XAMLの方が宣言的に画面を定義できるからですが、決してコードビハインドを使用してはならないという訳ではないことに注意してください。

MVVMの最後の要素であるViewModelは、プレゼンテーションロジックを表現し、画面に表示・編集する値をプロパティとして保持し、またボタン押下時などに実行すべき処理をコマンドとして保持します。そして、ViewModelの最も重要な側面として「Model of the View(ビューのモデル)」を表現するというものがあります。つまりViewModelとは画面そのものを抽象化したもの、さらに言い換えると画面そのものをモデル化したものということです。

ViewとViewModelの状態は、常に同期が行われるのがMVVMでの大きな特徴です。この同期は主にデータバインドとデータトリガ―の機能により実現します。（ただし、高度な同期についてはビヘイビアを自作する必要に迫られることもあります。）ViewModelの状態変化はViewの状態変化をもたらし、また逆にViewの状態変化はViewModelの状態変化をもたらします。ただし考え方としては、ViewとViewModelは対等の関係ではなく、ViewModelが主で、Viewが従の、主従関係にあると考えた方がよいでしょう。

Viewには画面コントロール、画面レイアウト、フォント、色彩、アニメーションなどの画面のあらゆる要素が存在しています。しかし、これらを細かくコントロールしたくないし、抽象的かつ容易に扱いたいのです。そこにViewModelの価値があります。実は、同期の仕組みにより、画面を抽象化したViewModelに対してプログラミングを行うことで、間接的にViewをコントロールできます。つまり、高い抽象を保ったまま画面をコントロールできるということです。これこそがMVVMのもっとも大きなメリットなのです。

□[原則１]ViewModelをモデリングの対象として認識すること

Viewでは、画面コントロール、画面レイアウト、フォント、色彩を司り、ViewModelでは画面に表示する値やコマンドを司ると前述しました。しかし、「ViewModelにてフォントや色彩を保持してはいけないのか？」というと実はそんなことはないのです。

実は本来のViewModelとは、「あなたが画面において制御したいと考えたもの」です。これはつまり、あなたが画面において何が重要であり、また何を無視すべきなのかを判断したモデリングの結果がViewModelであるということです。

そういった意味において、フォントや色彩が重要であると考えた場合には、ViewModelにこれらが含まれることは全く問題ありません。しかし、確かに多くの場合にフォントや色彩などをViewModelは保持しません。これはどういったことなのでしょうか？例を挙げて説明しましょう。

「期限が迫っている項目を赤く強調表示したい」というストーリーを考えてみましょう。この場合「期限が迫っている項目として強調表示すべきか」ということが画面の意図として重要となります。このため、ViewModelでは強調表示するかどうかのBooleanのフラグを保持することになり、この抽象化されたフラグに対してプログラミングを行い、画面をコントロールします。

一方、強調表示するために、赤くするのか、フォントを変えるのか、アニメーションを行うのか、あるいはその組み合わせを実行するのかは画面の抽象からすると重要ではありません。このためこれはView側の役割となり、データトリガ―機能などでこのViewModelのフラグを監視して、赤くするといったことを実現します。

ViewModelによる抽象化された画面に対するプログラミングの実現と、ViewModelとViewの主従関係とはこういったことを指しています。そして、フォントや色彩がViewModelにて保持されることがあまりないのは、画面の意図のレベルにおいて重要と判断されることが少ないからということになります。

画面そのものをモデル化したものがViewModelであるという考え方は、いくら強調しても強調しすぎることはありません。これは、ビジネスをモデル化してドメインモデルを作成するように、画面をモデル化してViewModelを作成する必要があるということです。漫然と開発してもドメインモデルが生まれないのと同様に、積極的にViewModelをモデリングしないとViewModelが生まれることもありません。

[原則１]ViewModelをモデリングの対象として認識すること

□ViewModel設計の原則
ここまで、ViewModel設計のl1つ目の原則として「ViewModelをモデリングの対象として認識すること」を説明してきました。今回ブログの最後に唐突ではありますが、本シリーズのテーマとなっているViewModel設計の原則を以下に列挙します。

・[原則１]ViewModelをモデリングの対象として認識すること
・[原則２]画面定義後、Viewの実装の前にViewModelの（簡易）設計を行うこと
・[原則３]ViewModel設計を画面設計に位置づけ積極的に設計すること
・[原則４]あらゆる画面の状態をViewModelでの状態としてモデル化すること
・[原則５]イベントではなく、ViewModelの状態によって画面を制御すること
・[原則６]いつでもViewを再構成できるだけの情報をViewModelに保持させること
・[原則７]ViewとViewModelとは平行なツリー関係を維持すること
・[原則８]ViewModelツリーの親子関係は慎重に設計し、親は子に依存しても、子は親に依存させないこと

（※しっかりとまとめきれていないので、今後変更される可能性があります）

これらの原則の詳細は次回以降に説明します。

以上。

「MVVMでダイアログ表示のためにメッセンジャーを使用するのはおかしいのでは？」 -ダイアログ表示を画面状態としてモデル化する-

2011-10-11T18:28:00.008+09:00

[2012/01/05 補足]
本記事を記述した後、ダイアログ表示のためにライブラリを作成しました。このライブラリの紹介と解説のために「MVVMでメッセンジャーを使わずにダイアログを表示する(MVVM Dialog Behaviorライブラリ提供)」と題したブログを改めて記述しましたので、必要に応じてこちらをご参照ください。

MVVMでダイアログ表示をするためにメッセンジャーを使うのは、現在では最も主流の方法でしょう。しかし以前、MVVMの説明を行ってすぐの技術者に「MVVMでダイアログ表示のためにメッセンジャーを使用するのはおかしいのでは？」と聞かれたとき、説明を続けられずに途中で窮してしまったことがあります。

MVVMパターンはPresentation Modelパターンの一種であり、ViewModelに抽象化された画面状態を保持します。一方、メッセンジャーを使用する方法は、処理の起動であって、あくまでイベントを送るようなものであり、画面状態とは相容れない考え方です。

イメージボタンのようなボタンの中のコンテンツや、MetroUIのようなタイルの中のコンテンツが画面状態と認められる一方で、どうしてダイアログ表示は画面の状態とは認められないのでしょうか？疑問に思い始め、今ではダイアログ表示は画面の状態であるという考え方を支持しています。

それでは、メッセジャーを使わずにダイアログ表示を実現するにはどうすればよいのでしょうか。最近になって考えている方法をご紹介します。なお残念ながら、この方法は実プロジェクトで実績を積んでいません。あくまで考え方とサンプルとしてお楽しみください。

メッセンジャーを使わずに、ダイアログを画面状態として扱うためには、改めてPresentation Modelパターンに立ち戻る必要があります。

Presentation Modelパターンは、画面の抽象的な状態を表現し、その抽象レベルのまま画面を管理するための方法です。ViewではなくPresentation Modelが主体となるため、スタートとしてダイアログ表示を抽象的にとらえるとどのようなPresentaion Modelとなるのかをまず考える必要があります。

MVVMパターンでは、Presentation ModelはView Modelのことですので、つまるところ、ダイアログ表示をViewModelとして設計するとどのようになるのかということから考える必要があるということです。

ダイアログ表示を比較的単純にとらえた場合、モデルとしては以下のようになります。

MainViewModel ◆------ 0,1 DialogViewModel

MainViewModelがダイアログ呼び出し元のViewModelとして存在します。

そして、ダイアログが表示されているかどうかは、MainViewModelが持つDialogViewModel型の属性に、インスタンスが存在するかNullかで判断するというモデルです。これは、上記の「0,1」という多重度に現れています。つまりダイアログ表示を行うためには、MainViewModelが持つDialogViewModel型の属性にDialogViewModelのインスタンスをセットし、ダイアログクローズのためにはNullにセットしなおせばよいことになります。

まずは、MainViewModelのコード例です。

public class MainViewModel
    {
        private DialogViewModel _DialogViewModel;

        public DialogViewModel DialogViewModel
        {
            get
            {
                return _DialogViewModel;
            }
            set
            {
                if (_DialogViewModel != value)
                {
                    _DialogViewModel = value;
                    OnPropertyChanged("DialogViewModel");
                }
            }
        }

        private InvokeCommand _OpenDialogCommand;
        public InvokeCommand OpenDialogCommand
        {
            get
            {
                if (_OpenDialogCommand == null)
                {
                    _OpenDialogCommand = new InvokeCommand(OpenDialog);
                }
                return _OpenDialogCommand;
            }
        }

        public void OpenDialog()
        {
            // ダイアログオープン
            DialogViewModel = new DialogViewModel(CloseDialogAction) { UserName = "ユーザ名だよ", Password = "パスワードだよ" };
        }

        public void CloseDialogAction()
        {
            // ダイアログクローズ
            DialogViewModel = null;
        }
    }

まず注目すべきは、ダイアログオープンのために、 DialogViewMode属性へのインスタンスのセットしか行っていない点です。そして、ダイアログに引き渡すべき、ユーザ名やパスワードがViewModelのプロパティによる単純な受け渡しで実現できており、メッセンジャーのように値の引き渡しや値の返り値を意識したコーディングではなくなっています。このように、ダイアログでの間の連携がしやすいのは、ダイアログを画面状態とした際のメリットです。

また、CloseDialogAction()メソッドでは、ダイアログクローズのためには、DialogViewMode属性にNullを設定しています。なお、ここで問題になるのが、どこからこのCloseDialogAction（）メソッドを呼び出すのかということです。ここでは、ダイアログ側からのクローズを考慮して、このメソッド自体をDialogViewModelのコンストラクタに渡して、呼び出せるようにしていることに注意してください。このあたりの実装方法は、いろいろ考えられそうですので、それぞれのプロジェクトに合わせて実装すればよいと思います。

次に、DialogViewModelのコード例です。

public class DialogViewModel
    {
        public Action CloseAction;

        public DialogViewModel(Action closeAction)
        {
            CloseAction = closeAction;
        }

        private String _UserName;
        public String UserName
        {
            get
            {
                return _UserName;
            }
            set
            {
                if (_UserName != value)
                {
                    _UserName = value;
                    OnPropertyChanged("UserName");
                }
            }
        }

        private String _Password;
        public String Password
        {
            get
            {
                return _Password;
            }
            set
            {
                if (_Password != value)
                {
                    _Password = value;
                    OnPropertyChanged("Password");
                }
            }
        }

        private InvokeCommand _LoginCommand;
        public InvokeCommand LoginCommand
        {
            get
            {
                if (_LoginCommand == null)
                {
                    _LoginCommand = new InvokeCommand(Login);
                }
                return _LoginCommand;
            }
        }

        private InvokeCommand _CancelCommand;
        public InvokeCommand CancelCommand
        {
            get
            {
                if (_CancelCommand == null)
                {
                    _CancelCommand = new InvokeCommand(Cancel);
                }
                return _CancelCommand;
            }
        }

        public void Login()
        {
            if (DoLogin())
            {
                CloseAction();
            }
        }

        public void Cancel()
        {
            CloseAction();
        }

        public bool DoLogin()
        {
            // 本来はログイン処理を記述する
            return true;
        }

ログインダイアログをイメージして、ユーザ名とパスワードの属性を用意しています。大したコードでもありませんが、先ほど説明したとおり、自身のダイアログをクローズするために、MainViewModelから渡されたCloseDialogAction()メソッドをコールバックしている点はご注意ください。

このDialogViewModelのインスタンスのセットに合わせて、画面側でダイアログオープンと、クローズを同期するには、添付ビヘイビアを使用する必要があります（なお、この添付ビヘイビアは、一度作成すれば他のダイアログでも使いまわすことが可能です）。まずは、この添付ビヘイビアをXamlで使用した場合の例から見てみます。

 <Window x:Class="Local.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:Local"
        Title="MainWindow" Height="350" Width="525" x:Name="This" 
        local:DialogBehavior.Content="{Binding DialogViewModel}">
    <Window.DataContext>
        <local:MainViewModel/>
    </Window.DataContext>
    <local:DialogBehavior.ContentTemplate>
        <DataTemplate>
            <StackPanel Margin="30" Width="300" Height="200">
                <TextBox Text="{Binding UserName}" />
                <TextBox Text="{Binding Password}" />
                <StackPanel Orientation="Horizontal">
                    <Button Content="ログイン" Command="{Binding LoginCommand}"/>
                    <Button Content="キャンセル" Command="{Binding CancelCommand}"/>
                </StackPanel>
            </StackPanel>
        </DataTemplate>
    </local:DialogBehavior.ContentTemplate>
    <StackPanel>
        <Button Content="Login Button" Height="50" Width="150" Command="{Binding OpenDialogCommand}" />
    </StackPanel>
</Window>

添付ビヘイビアは、local:DialogBehavior.Contentとlocal:DialogBehavior.ContentTemplateがWindowに対して指定されています。

　Contentの添付プロパティはダイアログを表示する際に使用されるViewModelを指定します。このプロパティにViewModelがセットされている間ダイアログが表示されます。Nullになった場合にはダイアログがクローズします。

　ContentTemplate添付プロパティは、ダイアログ表示のためのデータテンプレートです。そのDataContextには、自動的に先ほどのContentのViewModelが設定されるものとします。

なお、この画面は以下のように表示されます。

□メインウィンドウ

□ダイアログ（メインウィンドウの「Login Button」で起動される）

そして、この添付ビヘイビアの実装は以下の通りです。

     public class DialogBehavior:DependencyObject
    {
        public static readonly DependencyProperty ContentTemplateProperty =
        DependencyProperty.RegisterAttached(
        "ContentTemplate",
        typeof(DataTemplate),
        typeof(DialogBehavior),
        new UIPropertyMetadata(null, (depObj, e) =>
         {
             var self = depObj as FrameworkElement;

             OnPropertyChanged(self, e);
         }));

        public static readonly DependencyProperty ContentProperty =
        DependencyProperty.RegisterAttached(
        "Content",
        typeof(Object),
        typeof(DialogBehavior),
        new UIPropertyMetadata(null, (depObj, e) =>
         {
             var self = depObj as FrameworkElement;

             OnPropertyChanged(self, e);
         }));

        public static readonly DependencyProperty DialogProperty =
        DependencyProperty.RegisterAttached(
        "Dialog",
        typeof(Window),
        typeof(DialogBehavior));

        public static Object GetContent(FrameworkElement element)
        {
            return (Object)element.GetValue(ContentProperty);
        }

        public static void SetContent(FrameworkElement element, DataTemplate val)
        {
            element.SetValue(ContentProperty, val);
        }

        public static DataTemplate GetContentTemplate(FrameworkElement element)
        {
            return (DataTemplate)element.GetValue(ContentTemplateProperty);
        }

        public static void SetContentTemplate(FrameworkElement element, DataTemplate val)
        {
            element.SetValue(ContentTemplateProperty, val);
        }

        private static Window GetDialog(FrameworkElement element)
        {
            return (Window)element.GetValue(DialogProperty);
        }

        private static void SetDialog(FrameworkElement element, Window val)
        {
            element.SetValue(DialogProperty, val);
        }

        public static void OnPropertyChanged(FrameworkElement self, DependencyPropertyChangedEventArgs args)
        {
            if (GetContentTemplate(self) != null)
            {
                if (GetDialog(self) != null)
                {
                    CloseDialog(self);
                }

                if (GetContent(self) != null)
                {
                    OpenDialog(self);
                }
            }
        }

        private static void OpenDialog(FrameworkElement self)
        {
            var dialog = new Window();
            dialog.WindowStyle = WindowStyle.None;
            dialog.ContentTemplate = GetContentTemplate(self);
            dialog.Content = GetContent(self);
            dialog.SizeToContent = SizeToContent.WidthAndHeight;

            SetDialog(self, dialog);
            dialog.ShowDialog();
        }

        private static void CloseDialog(FrameworkElement self)
        {
            var dialog = GetDialog(self);
            dialog.Close();
            SetDialog(self, null);
        }
    }

定型コードが多いのですが、大したことはやっていません。注意点としてあえて言うなら、表示させているダイアログのインスタンスを内部的に保持するためにプライベートの添付プロパティとして「Dialog」を使用していることぐらいでしょうか。

さて、ダイアログ表示を画面状態として扱う方法を見てきました。私の個人的な意見ですが、ダイアログを画面状態として明示的に扱う方法のほうが、ダイアログ表示を十分に抽象化していて連携を行いやすく、Presentation Modelパターンにより準拠していると思われます。今後はメッセンジャーを使用しなくなっていくのではないでしょうか。

今回のサンプルは、まだ実プロジェクトで使用していないため、十分な実績を積んだ方法としてすぐにお勧めすることはできません。あくまで方向性のご提案ですので、その点ご理解いただければ幸いです。

以上。