※今日は小難しい話で今後に関係ないのでスキップしていただいてもOKです。
世の中ではWPFといったらMVVM（Model-View-ViewModel）パターンという認識ができつつあり、
MVVMにどれだけ厳密に従うか、といった話題を目にすることが多くなったような気がします。
・ViewModelからViewへの依存関係は持たない
・ViewはXamlで書いて、コードビハインドにはコードを持たない
・ViewModelはViewを意識した作りにしない
この連載ではMVVMパターンを使っていますが、
そういう意味ではかなりぬるいMVVMパターンです。
厳密に従った方が、特に大規模な多人数開発において
コードの理解性や保守性が向上しますが、
往々にして生産性（コードを書く時間）との両立は難しい場合が多いです。
Modelへの単純なアクセスのためのプロパティを
ViewModelに大量に追加することは、MVVMで作ったら誰しも経験があるかとは思います。
ある意味、単純であってもコード量の増加は理解性の低下といえます。
また、MVVMの厳密性を守るためのコネクタが肥大化・複雑化したら本末転倒です。
ViewModelがUI(View)を意識するかどうかについても（注：依存するかどうかではないです）難しい問題であり、
完全にUIを意識しないViewModelを書けば、Viewは自由にカスタマイズできるようになりますが、
その分Viewで作り込まないといけない部分が増えることが予想されます。
ある程度はUIを意識した作りにしておいて、Viewはデータを単純に表示するだけという状況に近づければ、
Viewにバグが入り込む余地が減り、ViewModelまではUnitTestできるというMVVMの利点を活かせます。
場合によって一長一短ということです。
これらはプロジェクトの特性と与えられた時間などのトレードオフで検討していただきたいです。
また、私がWPFを始めた時は、よいコードとしてminiUMLが挙げられていて、
そのプロジェクトではMVVMではなくDM-V-VM（DataModel-View-ViewModel）が使われています。 これはMVVMに近いのですが、
ViewからViewModelとDataModel両方のアクセスを許し、
また、ViewModelだけではなくDataModelもWPFにべったりの作りとなっており、
その分シンプルで冗長なコードが少なくなっています。
まぁ作図ツールなのでデータとしては単なるXMLで、
Windowsのクライアント上にどう図形を表示するかがキモなので、
当然の判断のような気もします。
私感ですが、データが単純でUIが複雑なアプリケーションはDM-V-VMが、
逆にデータが複雑でUIが単純なアプリケーションはM-V-VMがあうのではないのでしょうか。
もちろん私が知らないだけで、もっといいパターンもあるかもしれません。
また、どれかを選んで厳密に従わなければならない、ということではなく、
そのパターンのいいところを理解して、うまくあわないところは柔軟にしたほうがいいと思うのです。
といわけで、この連載のコードも悪いところもいいところも（？）あると思いますので、
悪いところはまねしないで、工夫して使ってください！＜結局のところ今日はこれが言いたかった。
なんか、ネットで「あのソフトのソースコードはこうなっていたので・・・」という発言をちらほら見て
気になったので書いてみました。
DM-V-VMパターンが気になった方はMiniUMLで検索してソースコードを見てみてください。
あと、更新すると言って更新してなくてすみません。
新しいクライアントのイメージができあがらないのです。。
