WPFでプログラミングをする場合、UIはXAMLという専用言語を使います。
XAMLでレイアウトするコントロールはデータバインディングという機能でC#のオブジェクトと連動する仕組みとなっています。
これはViewとViewModelをつなぐ部分に相当し、これにModelを加えるとMVVMパターンに成ります。
こんな感じでWPFはMVVMパターンを想定した作りになっており、使わないといけないような雰囲気があります。
コードビハインドを使うとデータバインディングを使わないプログラミングが可能となるので、MVVMを破綻させる可能性があるので、使わないほうが良いという風潮があります。
WPFと同じGUIアプリを作るフレームワークにWinFormsがあります。WinFormsはWPFと比べて少し古く、より新しいWPFは上位互換的な立ち位置と思いがちです。（実際は互換性はほぼ無い）
そうなると、まずWPFでWinFormsと同じことが出来ることを想定しますが、データバインディングやMVVMを意識したプログラミングを行うと、実装が難しい機能があることに気が付きます。
往々にしてそのような場面でコードビハインドの出番となるわけですが、MVVMの原則を守ると考えると、よろしくない感じがします。
では、MVVMの原則は順守する必要があるのでしょうか？
考え方は人それぞれですが、MVVMの恩恵を最大限享受するためには順守した方が良いのは、間違いないところでしょう。
しかしながら、MVVMは万能で、全ての問題が解決できるのかというとそうではなく、一見様々アプリケーションに適用できそうなパターンにも見えますが、少数ながら向いていなアプリケーションも存在します。
また、MVVMの恩恵は疎結合によるプログラムの再利用が出来る点だと思いますが、ViewとViewModelを頑張って疎結合にしたとしても、アプリケーションに依存するため、他のアプリケーションでの再利用は困難です。Modelの部分は再利用可能ではありますが、これはMVVMに限った話ではなく、OOPのプログラミングでは、無意識に使われる概念だったりします。
WPFでは頑張ってXAMLとデータバインディングを使いView-ViewModel間を疎結合にしていますが、メリットの恩恵を受けることが出来る使い方は、意外と少なく、人によっては全く恩恵が受けることが出来ない場合も考えられます。
以前WPF+MVVM+DDDでツールアプリを作ろうとしたところ、ビジネスロジックが存在しない（薄い）のでドメイン層が不在の状態になり、設計を適用できない場面に遭遇したことがあります。目的に合わせたパターンや設計手法を選ぶ必要を学びました。
また、コードビハインドを多用しないと成立しないアプリケーションは、そもそもWPFに向いていない可能性があります。WinFormsなどの別のアプリケーションフレームワークを検討するのも良いかもしれません。
どうしてもWPFで作りたい場合、XAMLとデータバインディングを捨てることに成りますが、そのような人間は私を含め少数派だと思います。
コメント