WPFで開発を効率的に進めるためのポイントについて思ったこと

id:int128さんがWPFで開発を効率的に進めるためのポイントについて書かれていますが、個人的な思いと少し違うかも？と思ったため自分の言葉で考えて書いてみました。ご意見、ご指摘大歓迎とあるので遠慮なくいってみます！*1

WPFでは、ViewとModel(ドメインモデル)の間にViewModelと呼ばれるViewに特化したModel層を設けるパターンが提唱されています。これにより、ビジネスロジックとプレゼンテーションロジックと表示が綺麗に分離されて、保守性やテスト容易性の向上が期待できます。

Model-View-ViewModelパターンは個人的なイメージ（30分で書いた図なのでイマイチかも・・・）です。

画像が小さいのでクリックしてオリジナルサイズで見るかこのpptxを直接見てくださいorz

ポイントは？

ポイントは、図中にも書いてありますが以下の点です。

依存関係はView → ViewModel → Modelである
ViewからViewModelはBindingを使ってViewModelのプロパティとViewの部品のプロパティの同期をとる
Viewで発生したイベントはCommandを通じてViewModelに伝える
- Command層を設けることでViewでのイベントハンドラによる引数の違いを吸収できる
- CommandをサポートしていないコントロールでもBehaviorを使うことで任意のイベントをCommandに関連付けることが出来ます。
ViewModelとModelではINotifyPropertyChangedとIDataErrorInfoを実装して変更通知と・エラーの通知を実装します

あと、id:int128さんの記事で気になったのはLINQ to SQLを採用するというところです。LINQ to SQLは終わってしまうテクノロジなのでEntity Frameworkか従来通りのADO.NETでDACを構築する方法が無難だと思っています。

データアクセスをViewModelでやる？？

以下の部分も、ViewModelでデータアクセスを実装するように受け取れますが、基本的にModel層で隠ぺいしてViewModelでは意識しないことになると考えています。

この手法を利用すると、デザインモードで確認しながらビューモデルのデータアクセスを作り込んでいくことができます。
いちいち実行しなくていいので効率的！

色々書きましたが

とまぁ、基本理念を知った上で、今ある自分の現実と照らし合わせて色んな要因が絡み合ったドロドロした状態での落としどころというのはあると思います。
なのでLINQ to SQLを使わないといけないとか、ViewModelとModelが混在しちゃってるような実装になってしまうとかという現実になってしまうことはあると思います。イベントハンドラを使ってViewModelのメソッドを呼ぶというのもあり得ると思います。

でも、本来どうあるべきかという点はきちんと意識して最初は理想的な実装になるように設計すべきだと思います。まぁでも、なかなか理想を貫くのは難しいところですよね。悩ましい。