業務系アプリでWPFを使うメリットがなかった件
非常によくわかるお話だった。特にここ。
MVVMの原則に従って一生懸命、コードビハインドからコードを追い出したところでほとんどメリットが感じられません。
業務系のアプリはデスクトップのテンキーをベースに操作ができることを求められるから、キー関連のイベントを拾わざるをえなくなり、結局コードビハインドは追い出せない。ボタンをクリックするの？Enterで検索開始すればいいじゃない、とかさ。
MVVMをやる時に一番困るのがコードビハインドからViewModelに処理を投げてそのViewModelからUIにメッセージを返すところ。ココがよくわからなかった。WPFのMVVMは敷居が高く、オレオレ実装でやると予期せぬバグを生み出す温床になります。同じデータなのにAさんとBさんで表示結果が1個のセルだけ違うというバグが...
WPFはWindowsFormの感覚で作ると火傷するということです。全く別物と考えていいでしょう。あと、画面がどうしても重たい。UIを仮想化している為だと思うがUserControlに色々コンポーネントを付け足していくスタイルだと仮想化されたUIが更に重くなる(JSでいうDOMみたいなやつ)みたいで、画面の描画がロースペックなマシンだと時間がかかる。これをチューニングするとなると、作り方を大きく変えないといけない。
WPFの利点にコントロールの外観を自由に変更できることがある。同じデータを円グラフとテーブルの表で表示する、なんてことは大得意。でも、そのメリットを享受できるケースは業務系のアプリにおいてとても限られている。
振り返ってみるとWPFの一番のメリットは画面サイズが固定でなくても良い所と、依存関係プロパティ、データバインディングの３つだった気がした。
WPFは画面サイズやウインドウサイズに応じて自動的に画面の再描画が走るので、相対配置に対応している。Windowsフォームは原則サイズ固定だけど、下記のやり方を使えばフレキシブルにできるみたい。
依存関係プロパティってのは、CSSのように html { font-size:20px;} って指定すると、全てのfont-sizeプロパティを持つUI(p,span,td...など)に変更が伝搬される仕組みのこと。Styleとコントロールは完全に独立されている設計だから。Windowsフォームでは出来なかった。やるとすれば親Formで再帰でループ回してfontsizeプロパティを持ってるなら変更する感じになるかな。別にこれじゃなくてもええけど、他にやり方を知らない。
データバインディングについてはWindowsフォームでも出来る。コードビハインドで画面のViewを内包したモデルを作ってインスタンス作ればいいだけ。多分オブジェクトのネストにも対応してくれるだろう。
WindowsFormsでの単項データバインドまわり | tocsworld
結局、Windowsフォームでもやりたいことはできるし、画面のコンポーネントがダサいというか古臭い所はあるだろうけど、WPFより操作は簡単で作りやすい。デスクトップアプリはWebアプリの３倍難しいのが僕の肌感。Web上に乗っかってるサンプルコードをちょいちょいで見様見真似で....っていうのは困難。GUIのハンドリングは実にめんどくさい。高い操作性を得るためなら、クライアントに配るライセンスがフリーのツールを買うのが最も正しい選択だなと、3ヶ月WPFをどっぷりやっておもいました。
おわり。
