教えてください:Windows Forms 開発者が WPF / Silverlight に移行するには何がたいへんですか?


今月、Windows Forms Developers: Tell me about your applications という記事があって、16のコメントが書かれていました。「MDI がないため」という理由が多かったのが意外でした。ここにコメントした一人は Why people don’t switch from WinForms to WPF という記事を書き、以下の理由を述べています。

  1. ビジネス コントロールがない
  2. デザイン システムが複雑
  3. WinFormの開発者としての経験が生かせない
  4. ほとんどの WPF アプリ はいけてない

私のブログを読んでいる人に Windows Forms 開発者はあまりいないと思いますが、Windows Forms 開発者にの方に WPF / Silverlight に移行していただくには、MSDN などでどういう情報を公開すればよいのか検討しているので、開発者として(ビジネス上の理由は別にして)Windows Forms から  WPF / Silverlight への移行が困難な理由をコメントとして残していただけると幸いです。

【追記】移行(Migration)には3つの意味があるので、それを明確にしたほうがよいですね。基本的には新しい(完全にではなくても既存のアプリの一部でも)プロジェクトに WPF を使ってほしいけど何が問題かを知りたいので、①と②かな...

  1. 技術者のスキルの移行
  2. Windows Forms と WPF との相互運用性
  3. Windows Forms から WPF へのポーティング
Comments (7)

  1. haro says:

    日頃思っていることを...

    ・重い。特に DataGrid を全画面表示した場合のスクロール。

    ・MVVM。敷居が高いのと、必須と考えて WPF / SL 共に敬遠してる人もいる。

    ・XAML を直接編集する場合が多すぎる。

     Forms のように Tab Order を連続で指定できないのは最も苦痛。

    ・標準の ControlTemplate の見た目。

     WPF で小さいアプリを作る場合はそのまま使うことになるが、

     XP では違和感が大きい。また TextBox は Forms より大きいため、

     間延びして見えるので敬遠。

    ・コントロール不足。

    ・外字のサポート。SL では扱えず、WPF 4 では改悪。

  2. trapemiya says:

    >1.ビジネス コントロールがない

    具体的にどういうコントロールを指しているのかわからないのですが、XAMLで比較的簡単にそれと同様なものを実現できると思います。

    >2.デザイン システムが複雑

    確かに複雑ですが、私はそれを求めていました。例えばスケジュール表を作成し、その中のスケジュールをクリックして操作するなんてことはWinFormでは簡単に実現できません。Webアプリでは比較的簡単なので、このケースではWebアプリでの構築を検討してきました。ところがWPFではこのような柔軟性も備えています。WinFormがWeb画面の柔軟性を手に入れたものがWPFとも言えるんじゃないかと思います。

    >3.WinFormの開発者としての経験が生かせない

    MVVMで構築せず、イベントプロシージャで組んでいけばそんなに変わらないんじゃないかと思います。ただ、MVVMで組むことがスタンダード化しつつありますから、そこは大きなハードルだと思います。

    >4.ほとんどの WPF アプリ はいけてない

    アニメーションやエフェクトを効果的に使うことにより、一度経験すればもうWinFormには戻れなくなるんじゃないかと思います。私自身、業務アプリ中心で作成していますが、もうWinFormでは開発したくないというのが正直な感想です。

    そういうわけで、WPF / Silverlight への移行が困難な理由は私自身は全くと言っていいほどありませんが、WPFを学び始めたころ、依存関係プロパティや添付プロパティの概念がしっくりと理解できず、ネット上を探し回った経験があります。あとはMVVMの問題があります。これについては標準化がされていませんし、みなさん試行錯誤されている段階で、余計に敷居が高く感じるのじゃないかと思います。この辺り、IDEでフレームワーク的にサポートしてくれるとぐっと敷居が下がるのではないかと思います。現段階ではMVVMのパターン例などの情報が多く掲載されていると良いのではないかと思います。

  3. 伊藤達也 says:

    自分なりの意見をブログにエントリーしてみました。

    blogs.bitlan.net/ito

    Windows Forms 開発者が WPF に移行する方法

    blogs.bitlan.net/ito

    Windows Forms 開発者が WPF に移行する方法 2

  4. hotrit says:

    ものすごい低レベルなことで申し訳ないが、

     ・XAMLという新しい言語を覚えにゃならん。

     ・XAMLのが複雑すぎ。階層構造もそうだし、記述方法もそう。

      感覚的に階層構造が追える構造になってればいいんだがぜんぜん追えない。

     ・VS2010のデザイナではほとんどのことができないためゴリゴリ手入力となってしまう。

      とさらに結局、WindowsFomrs同等のUIとなってしまいWPF使った意味がなくなってしまう。

     ・Viewとロジックの依存度が低くなるということが売りだが、

      それによって、WindowsFormsにおいては、ロジックで単に宣言するだけでよかったものを、

      WPF/Silverlightにおいては、ロジックにおいてもXAMLにおいても宣言(XAMLではResource)

      しなければならないため、なんか2度手間に思えて仕方ない。

      (RelativeSource={RelativeSource ・・・も2度手間感ありまくり)

     ・Silverlightなんてほとんどが非同期なため、WindowsFormsのような感覚でコード書くと

      ことごとく失敗する(エラーにはならない)。

      View(UI)とは別のスレッドで実行されているのなら、そのスレッド内での同期実行できるメソッドが

      あったっていいようなものを。

      で、最初のころはAction連発なコードとなる。

     ・同じプロパティなのにプロパティ名が違う。XAMLだとCanvas.Top、ロジックだとCanvas.TopProperty。

     ・プロパティウィンドウの構成が違うこと。

      特に色選択なんて色名が表示されるが色そのものは表示されないものだからどんな色かさっぱりわからん。

     ・ユーザーコントロールを作った際に、シリアライズできないものは、XAML内で完結できない。

     ・ここは日本。こと日本語に関するバグがWPFにおいては結構目立つ。

     ・スタイルなどを編集する場合に、デフォルトのコントロールテンプレートを参考にしようと思ったとき、

      Blendではテンプレートの編集で、デフォルトのテンプレートをXAMLファイル内にはきだされるため

      これを参照することでできるが、VSにはその機能がないため、

      xamlWriterで吐き出して見るか、MSDNのページにいって見るしかない

      (私が知らないだけでこの方法以外にもあるかもしれんが)

      かといって、コントロールにおいては100行近いデフォルトテンプレートもあるため、

      XAMLの複雑さも手伝って、把握するのが一苦労。

     ・ならBlend買えばいいじゃんって?VS2010自体重いのに、さらに別のツールを起動しろってか。

      低スペ乙?会社で高スペックなマシンが使えるんだったら使いたいよ。

      そもそもBlend自体も問題。デザイナー向けに作られたということだが、

      パッケージソフトを開発しているような会社ではデザイナーが別にいるだろうが、

      業務アプリを作っている会社においてデザイナーがいるところなんてほとんどない。

      (5年前、都内にある100社のソフトハウスに直接電話をして調査したらデザイナーがいるのは11社だった)

      金のある会社に対してはいいツールだが、金のない会社には用がないツール。

     ・WindowsFormsのコントロールとほぼ同等なWPFコントロールがあったとしても、プリミティブなコントロール

      ならWindowsFormsコントロールの感覚で扱えるが、ちょっと複雑なコントロールとなってくると、

      定義されているイベントやらプロパティやらがほとんどちがうため、WindowsFormsの開発経験者は

      WindowsFormsでの知識が邪魔をしてしまい逆に開発効率を下げてしまう。

     ・頭悪いもんだからMSDNだけでは理解できずになんかセミナーないかと思って調べてみたらあるにはあったが、

      12万という超ボッタクリな料金。金額もさることながら、協力会社として働いている俺(個人事業主)は

      派遣社員と同等となり自会社及び出向先会社はそんな金払わんという状況で行きたくても行けない。

     ・頭いいやつはすぐに理解できるだろうが、俺のように頭悪いやつには理解するには一苦労。

      頭いいやつとのギャップが発生してしまい結果会社から捨てられる。

    WindowsForms未経験者はそんな苦労せずにWPF/Silverlightのプログラミングができるようになるだろうが、

    WindowsForms経験者は一苦労する。

  5. Nimura says:

    私自身はWPFに移行してしまったのですが、以前所属していた組織で新商品を開発するとなった場合、WPFには移行できなかったと思います。その理由を考えました。(下記にWinFormアプリといっているものは、ここでの意味合いとしてはMFCアプリも含みます)

    ・過去の資産を活かすのにコストがかかる/過去と同じ事をするのに余計時間がかかる

     全く新しいプロジェクトだとしても、過去に動作している似たようなコードをコピペしたり、もちろんモジュール化されているものであればそれを使用するといったことがあります。WPFアプリにしたことで、今まで当たり前のように出来ていたことでさえ、結合テストや実装方法の調査をしなくてはらなず、その追加コストを認めてもらえることは難しいと思います。

     また、実際に作ってみると、カラーピッカーコントロールが標準でなかったり(探せばすぐみつかりますが)、同じような動きをするコントロールが異常に遅かったり(自分の場合はフォント選択コンボボックス)、そういう物に出くわすとこれから先の開発に疑心暗鬼にならざるを得ません。

    ・工数の見積もりが難しい

     WinForm等の今まで慣れたプラットフォームを使えば、UIのモックからどれくらいの時間で実装できるか大体の検討がつきます。しかし、いくらデザイナーが便利で進化しているとはいえ、新しいプラットフォームの開発にどのくらいかかるかわかりません。

     私の経験では、見積もり確度の低さが原因でNGが出たことが多かったです。

    ・マイクロソフト製アプリが "WinForm"なので、WPFアプリは異端

     顧客レベルでは、Windows XP が主流である以上、普段使っているIEやエクスプローラー、メモ帳、Office などがWindowsアプリの象徴です。

     お客さんにとっては、WinFormアプリが "普通" であり、それしか知らないとも言えます。

     場合によっては、見慣れないWPFアプリを”使いにくそう”と感じる人もいるかもしれません。

     逆に、WindowsPhone7 で WindowsMobile6.5 のようなUXアプリを作ろうという人は少ないんじゃないでしょうか。

    リッチアプリがそのプラットフォームの基準となる必要があると思います。

    たとえば、世の中のPCの大半がスレート化するとか。もしそうなれば、全力でWPFやSLに移行すると思います。

    マウスとウィンドウが主体、しかも WindowsXP がメインターゲットだとすると、お客さんの本心としてリッチアプリが望まれる環境にはならない気がします。

    Office、IE、エクスプローラーなどが、完全にWPF的な高UXになり、WinFormアプリの方が違和感を感じるようになれば、おそらく半年ぐらいで状況は一転するでしょう。WPFに不満のある開発者も、世の中の標準には勝てないと思います。

  6. Nimura says:

    立て続けにすみません。

    どういう情報があればよいか、でしたね。

    次のようなシナリオはどうでしょう。

    「過去のWinForm/MFCアプリのユーザーインターフェスのみをWPF化するテクニック」

    ・WinFormアプリのロジックとUIの分離テクニック

    ・WinForm内のプロパティをWPFのViewModelと連結するテクニック

    ・信頼できる有料コンポーネントの紹介

    この場合のメリット

    ・UIの実装/カスタマイズは、すべて外注・調達できる =自社制作より安くて高品質

    ・顧客要望への応答スピードが高い

    もちろん、今までより高いUXが提供できるのは言うまでもないです。

    外注する予算なんてないと言う方もいらっしゃるかもしれませんが、ご自身の固定費(間接部門の固定費やUIの品質保証費用も含みます)を厳密に計算し、仕様変更のリスク費用もに合わせて、UX専門企業に発注するコストや有料のコンポーネントを購入するコストを大局的に比較すれば、今ロジックとUIを分離して、完全に外注できる体制に取った方がオトクである、という言い方が可能かと思います。

    また、UIを分離すれば、操作性の部分は顧客を交えたアジャイル的開発が可能ですので、実際に動く物を見せながらの開発も可能となり、低コストで顧客満足度の高い製品開発も出来ると思います。

    標準のDataGridに不満がある場合は、有料のDataGridコンポーネントが、ものすごく沢山ありますから、そういう方法で解決できるのがWPFの良いところかと思います。

  7. だいぶ前の記事ですが says:

    WPFでMDI風にしようと思ってたんですが、標準では難しいんでしょうか?

    別の会社が作ってるWPFのアドオンまで購入して作る用途ではないので、できれば標準ライブラリで何とかしたいと思ってたんですが。

Skip to main content