非常によくわかるお話だった。特にここ。 kiwosuke.hatenablog.com MVVMの原則に従って一生懸命、コードビハインドからコードを追い出したところでほとんどメリットが感じられません。 業務系のアプリはデスクトップのテンキーをベースに操作ができることを求められるから、キー関連のイベントを拾わざるをえなくなり、結局コードビハインドは追い出せない。ボタンをクリックするの?Enterで検索開始すればいいじゃない、とかさ。 MVVMをやる時に一番困るのがコードビハインドからViewModelに処理を投げてそのViewModelからUIにメッセージを返すところ。ココがよくわからなかった。WPFのMVVMは敷居が高く、オレオレ実装でやると予期せぬバグを生み出す温床になります。同じデータなのにAさんとBさんで表示結果が1個のセルだけ違うというバグが... WPFはWindowsFormの
この2年ほど業務(新規開発・保守)でWPFを触ってみた感想をまとめてみたいと思います。 XAML習得のコストは必要となりますが、WindowsFormにはない表現の豊かさは大きなポイント。 WPFを経験した後、WindowsFormで作られたアプリを触ると旧世代のUIであることを痛感します。 業務システムといえどもこの印象の違いは大きいです。 Bindingも便利な仕組みですが、現時点(VS2013)では開発環境が貧弱(静的チェックなし、Bindingエラーも実行時のログ確認が必要)でバグの温床となりがち。 上手く動かない場合の原因追及も慣れを必要とします。 更にMVVMを取り入れた場合、よりXAML・WPFに対する理解が必要となり、旧来のWindowsFormよりも技術者の確保が難しいのではないかと。 MVVMでキレイに組むと技術者的には満足度が高いかもしれませんが、保守性に難があり、自
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く