Under17の「こたえ」もAngelaの「未来という名の答え」も好きな曲。
MVVMってものを色々と、作りながらあーでもないこーでもないと悩んでいたのだけれど、結局は「これでいいんじゃね？」と行きついた一つの答えというか、そんな結論をまとめてみたのでメモしておく。
図にまとめるとこんな感じ。上から行くと、
View部分
Viewクラスが一つ。ここが画面。ユーザーにみえる所。モノはFormだったり、aspxページだったり、Silverlightコンテンツだったりするけど、もちろん、ルックス重視で外面の良いタイプが適任。コントロールが配置されたり、表示されたりでイベントも発生させるし、イベントドリブンの簡単なコードはあるけれど、それ以外のことは全部ViewModelに丸投げｗ。
ViewModel部分
ViewModelクラス
外面だけ良い八方美人のViewを支える縁の下の力持ち、というか、パートナー、というか、執事。Viewとは１：１の関係で、Viewで発する色々なイベント処理やデータ処理の実体実働はここ。場合によっては複数のModelをコントロールしなくちゃだから、やることはたくさん。といっても、細かな処理についてはModelにさせてしまうので「あれしろ」「これしろ」とメソッド呼び出しするのがお仕事。何も考えていないViewModelのために「何を表示するのか」を定義したViewRecordも管理してくれていたりと、致せり尽くせり。
ViewRecordクラス
View部分に配置されるGridViewやDetailView用に作成する自己完結したクラス。各要素をプロパティで公開して、必要であればチェックメソッド何かを持っていたりする。ViewModelに属しているようでいてViewにも媚びている板挟みの立場ｗ
Model部分
ここはModelクラス－DataControlクラス－DataSourceクラスのトリオ。３兄弟か姉妹かグループなのかは判んないけどね。ModelとDataControlは、List （of DataRecord）というクラスを共有してうまく仕事を連携できるようにしてる。DataSourceはデータの内容そのものには何も関係してないから、気にしてないけどｗ
Modelクラス
ViewModelクラスとのやりとりを一気に引き受ける窓口で交渉人。実質のリーダーというか一番上。正体はDataControlのラッパークラスで、メソッドを公開して命令を受けて、連番処理とかキー付与とかそういう小細工が必要ならしてくれるけど、大体においてはその命令をそのまますぐ下のDataControlに丸投げｗ
DataControlクラス
Modelクラスから受けたメソッドを真面目にこつこつと処理する。List (of DataRecord)を持ち、データ処理の中心部分。真ん中はつらいよね。
DataSourceクラス
データ接続やロード処理だけを引き受けるクラス。データベースであれば接続切断やSQLの実行、ファイルであれば読み込みや書き込みをする。ModelクラスとDataControlクラスが「どこの」データを処理しているのか全く意識しなくて済んでいるのは実はこのクラスのおかげ。無関心を装って実は要？
DataRecordクラス
データベースであればテーブルと、ファイルであればファイルレコードと、それぞれ一致したデータ要素を持つクラス。要素はプロパティで公開。Modelが一緒に外部に公開しているけれども、実体はDataControlと密接な関係に……ってそれなんてトライアングラーｗ Modelクラスとのやり取りがある、さらにその上のViewModelクラスからも見守られていたりするヒロイン属性ｗ
いじょ。
時間とパワーがあれば、サンプルコードも書いてみたいんだけどな。
つか、擬人化してるのは、きっと気のせいｗ