WPFを業務で2年使ってみての感想

この2年ほど業務（新規開発・保守）でWPFを触ってみた感想をまとめてみたいと思います。

XAML習得のコストは必要となりますが、WindowsFormにはない表現の豊かさは大きなポイント。
WPFを経験した後、WindowsFormで作られたアプリを触ると旧世代のUIであることを痛感します。
業務システムといえどもこの印象の違いは大きいです。

Bindingも便利な仕組みですが、現時点(VS2013)では開発環境が貧弱（静的チェックなし、Bindingエラーも実行時のログ確認が必要）でバグの温床となりがち。
上手く動かない場合の原因追及も慣れを必要とします。

更にMVVMを取り入れた場合、よりXAML・WPFに対する理解が必要となり、旧来のWindowsFormよりも技術者の確保が難しいのではないかと。
MVVMでキレイに組むと技術者的には満足度が高いかもしれませんが、保守性に難があり、自己満足で終わりがちではないかと思います。

WPFの最大の売りは多彩なUIによるユーザー体験の豊かさであり、MVVMやBindingなどは必須の要素ではないと思います。
MVVMの原則に従って一生懸命、コードビハインドからコードを追い出したところでほとんどメリットが感じられません。
特にバリバリの業務アプリケーションはWebアプリのようなシンプルな画面制御ではなく、やれこのキーの組み合わせは短縮キーだ、Enter押したら入力チェックしつつ、次の項目へ飛べだの特殊な要件が発生しやすいので、ガチガチのMVVMはその度に標準が破壊されることになってしまいます。

現時点で僕が考えるベターな選択。
画面側のコードはWindowsFormライクなスタイルでイベントベースでコントロールを直接触っていく。
一見、泥臭く感じるかもしれませんが、面倒な挙動をMVVMやBindingで実現する方法を悩む必要もなく、コードビハインドはWindowsFormの技術者でも違和感はないので、保守担当者のアサインなどを視野に入れるとメリットが大きいと思います。
Bindingを使うのであれば外部に実装を晒さない共通部品などなら使ってもよいかもしれない・・・けれど現時点では使わないに越したことはないかと。
業務ロジックはサービス側で。
こうすれば画面側では制約なくコントロールを自由に扱えますし、業務ロジックからはコントロールを確実に排除できます。
画面コントロール⇒Binding用エンティティ⇒業務エンティティみたいなバケツリレーも要らなくなりますね。
自由度を考えるとMicrosoftのXMLWebサービスではなく、jsonを返すSOAPにしたいです。

とにかく出来るだけシンプルな作りが良いと思います。
DataAccessなどもEntityFrameWorkのような重厚長大で遅いものではなく、シンプルなDAクラスを共通部品として提供すればよいと思います。

結局のところ業務アプリの競争力の源泉は凝ったアーキテクチャではなく、操作性を中心としたユーザー体験の豊かさ、開発工数削減と保守性の高さからくる低コストだと考えています。