WPF対WinForms-Delphiプログラマーの視点？
私はWPFとWinFormsの主要なスレッドのほとんどを読みましたが、試してみた真の以前の技術（Winforms）と後継者（WPF）の間で決定するときにあなたが陥り得る不幸なあいまいさにはまっています。
私は長年のベテランDelphiプログラマーであり、ついにC＃への飛躍を遂げています。私の仲間のDelphiプログラマは、Delphiの名声を誇るAnders HejlsbergがC＃の設計者であることを知って興奮していることを理解します。 DelphiのVCLカスタムコンポーネント、特にマルチステップウィザードや子コンポーネントのコンテナとして機能するコンポーネントの作成に関係しているものには、強い依存症があります。
その背景を踏まえて、DelphiからC＃に切り替えた皆さんが、WinFormsとWPFのどちらを最初のアプリケーションを作成するかを決定する際に役立つことを願っています。コーディングや、本格的なオートコンプリートや適切なデバッガーのサポートなどのプロジェクトによってプロジェクトが成功または失敗する可能性がある場合、APIの機能と呼び出しに関するすぐに利用できる情報、さらにはバグの回避策を見つけることができるので、私は非常に焦っています。 。
2009年初頭の日付範囲のSOスレッドとコメントは、C＃UI開発コーディングを損なう可能性のあるフラストレーションの可能性に関して、WPFに大きな懸念を与えます。放棄されなくてもすぐに置き換えられる（WinForms）APIテクノロジを学習する時間も同様に厄介であり、WPFでのGPUサポートが試されています。
したがって、私の両義性。私はどちらの技術もまだ学習していないので、新たなスタートを切るまれな機会があり、WinFormsプログラマーがWPFに移行するときに人々がさまざまなスレッドで言及する大きな「非学習」曲線に直面する必要はありません。一方、WPFの使用があまりにも苛立たしい場合や、他の主要なマイナスの結果、せっかちなRAD私自身のような開発者である場合は、WPFが同じレベルに到達するまで、WinFormsのみを使用します。プログラマーとしての私の心理学に具体的な例を示すために、VBを使用し、その後Delphiを使用して、MFC、Windows初期のWindowsアプリの開発中に多くの開発者が苦しんできたUIライブラリMFCを回避することに私の運を後悔したことはありません。
また、Anders HejlsbergがWPFやWinForms、あるいはその両方のアーキテクチャに関与しているかどうか、また、どちらかのコードベースに組み込まれている創造的なビジョンと使いやすさに格差があるかどうかを知ることも安心です。最後に、Delphiプログラマのために、特にデバッガのサポートに関しては、WinFormsとは対照的にWPFを使用する場合の "IDEショック"について教えてください。 2011年に更新された就職市場のコメントもいただければ幸いです。
Delphiの背景を持っている場合、WinFormsに失望します。 VCLで簡単であったことをやろうとしますが、それが非常に難しい、または不可能でさえあることがわかります。 WPFは制限がはるかに少なくなります。
たとえば、以下はWinFormsの制限事項の一部です。
- WinFormsにはTActionに匹敵するものがないため、アクションを使ったコーディングに慣れている場合は、メニュー項目とツールバーボタン、および右クリックメニューで同じテキストとアイコンを共有し、有効化ロジックを一元化し、有効化状態を更新します。 OnUpdateを使用してバックグラウンドで... WinFormsを嫌うでしょう。
- WinFormsの古い（.NET 1.0ヴィンテージ）MainMenuは、メニュー項目の隣の画像をサポートしていません。新しい（.NET 2.0で導入された）MenuStripは バグに満ちています Microsoft 拒否します修正 （バグ修正により下位互換性が損なわれる可能性があるため）。
- 多くのコントロール、例えばTreeViewは、それらのVCLの対応物と比較してひどく機能不足です（痛々しいほど遅い、所有者による描画がない、多くのカスタマイズオプションがないなど）。
- Delphiで慣れている、サードパーティのコントロール開発者の活気に満ちたコミュニティに似ているものはありません。品質管理ライブラリは世の中にありますが、あなたはそれらの代金を支払います-VirtualTreeViewのような無料の製品はWinFormsにはありません。
WPFは、いくつかの点でWinFormsよりも少しだけ重要ですが、非常に拡張性があります。
- TActionのようなものが必要ですか？ WPFには、慣れているのと同じくらい豊富なICommandがあります（ただし、必ず読んでください Josh SmithのMVVM記事 -通常、状態が変化した場合は、コマンドを手動で有効/無効にする必要がありますが、彼のバージョンは、OnUpdateに慣れているように、バックグラウンドで有効化コードを自動的に起動します。
- メニューに画像が欲しいですか？それは組み込まれています（WinFormsのようにバグが多いわけではありません）。
- WinFormsはいくつかの重要なコントロールでowner-drawを省略しますが、代わりにWPFを使用している場合は、needowner-drawを行いません-あなたがTreeViewノードに黒のテキストとそれに続くかっこ内の青い数字を含めるには、それをDataTemplateに挿入するだけで機能し、醜いオーナー描画コードは必要ありません。
- サードパーティのコントロールが必要ですか？多くの場合、WinFormsの方法を拡張できるため、VCL開発者は夢を見ることしかできないため、それらは必要ありません。
WPFの学習曲線は非常に急ですが、良い本（例： " WPF 4 Unleashed "）を手に入れれば、最悪の事態を乗り越えるのに役立ちます。 WinFormsの方法を妨げないフレームワークを使用できることをうれしく思います。
私は通常、WPFを使った経験がなかったと言っている人にとても驚いています。私はC++/MFCからC＃/ WinFormsにC＃/ WPFに切り替えた開発者です。 WinFormsからWPFへの移行は簡単ではありませんでした。XAMLの学習はそれほど簡単ではないためです。 1つには、WinFormsに戻ることはできません。 WPFは素晴らしいです。
もう1つ気になるのは、WPFをUIだけに関連付ける方法です。 UIの設計が容易な点で、WinFormsよりも100倍優れていると思いますが、WPFを使用する理由は他にもたくさんあります。
- もちろん、UI。
- バインディング。ただの魔法です。 UIに続く最も強力な機能。 LOBアプリケーションは、これから最も恩恵を受けます。
- コマンド。
- 関心事の分離。デザイナーはデザイン、プログラマープログラムに取り組みます。
- 添付プロパティ。ソースコードなしでサードパーティコントロールの機能を拡張できます（ただし、この点は最初の点の一部である可能性があります）。
- Silverlightへの簡単な移行（WebとWP7の両方）
最後の点については、WPFを学ぶ理由としては同意できないかもしれませんが、私に尋ねると、それは最大のものの1つです。 WPFを習得すると、Silverlightに簡単に移行できます。 Silverlightは大きく成長しており、素晴らしいテクノロジーでもあります。
そして最大の理由は、それが未来だということです。 Silverlightと統合される可能性がありますが、スキルは同じままです。
だから、私はあなたにWPFの道を行くことを強くお勧めします。
明らかに、WPFは将来的に考える方法です。習得は難しいですが、プラットフォームは非常によく設計されており、柔軟性があります。
数行のアドバイス：
- 簡単に始めましょう：MVVMまたは派手なアニメーションのみを使用して最初のプロジェクトを実装しようとしないでください。ウィンドウ、ボタン、リストから簡単に始めましょう。
- DataBindingを利用します。
- Adam Nathanの本WPF Unleashedを購入してください。
私は最初にasp.net開発者であることに最初に注意する必要がありますが、以前はwinformsをたくさん使用したことがあります。 WPFへの切り替えは、1週間ほど（40時間以上）経過した後（imo）ほど大きくはありません。ほとんどが再び2番目の性質でした。
とにかく、少なくともこの本の出版社によれば、Anders HejlsbergはWPFを支えているアーキテクトの1人だと思います->
「WPFの背後にいるアーキテクトの1人として、クリスアンダーソンは「方法」だけでなく「理由」も巧みに説明しています。この本は、設計原則を理解したい人にとって優れたリソースです。およびWPFのベストプラクティス。」– Microsoft Corporationテクニカルフェロー、Anders Hejlsberg氏
http://www.Amazon.com/Essential-Windows-Presentation-Foundation-WPF/dp/0321374479
WinformsはDelphi開発とほとんど同じです。そしてもちろん、それには理由があります。 Delphi/Object PascalオブジェクトモデルがC＃に大きな影響を与えたように、フォームシステムもWinformsに影響を与えました。
WPFは物事の方向性のようです。 Winforms上に構築された以前のジェネレーションとは異なり、（豪華な！）VS2010 UIはWPFベースであると言われています。
快適ゾーンに留まりたい場合は、ウィンフォームを使用してください。最新かつ最高のものに夢中になる場合は、WPFに浸ってください。
私はDelphiプログラマではありませんが、はい、WinForm（多用）とWPF（中程度未満）の両方に取り組んできました。私は、WinFormからWPFに切り替えようとしている人のフラストレーションレベルにある程度同意します。 WPFがWinFormと比較してどれほど素晴らしく柔軟であるかを学び、確認してください。 Winformではなく、少なくともDelphiのバックグラウンドを持っている人にとっては、学習曲線が非常に長くなります。あなたにとっては、WinFormではなくWPFに移行する価値があることは間違いありません。
まず、以下のリンクを調べてください。
私はいくつかのWindowsフォームの作業（主にPocket PCで）に加えて、同じ原則を使用する他の非.NET環境をいくつか実行しました。 3年ほど前にWPFに移行したとき、最初の数か月間、私はそれを非難していました。最終的には「クリック」しただけで、振り返ってみませんでした。実際、次のプロジェクトでWindowsフォームに戻る必要があった場合、私は困惑するでしょう。
Windowsフォームが最後に更新されたのは2005年（VS 2005）です。それはまだ存在しますが、Microsoftによって改善されていません。 WPFはデスクトップアプリの新たなブロックです。そのため、MSツールを使用して.NETプラットフォームに移行するのであれば、それは間違いないでしょう。一部の人々はSilverlightをデスクトップソリューションとしてプッシュしていますが、それを可能性として見たところ、制限が多すぎることがわかりました（Webコンテキストでは意味があるかもしれませんが、デスクトップではそれほどではありません）。
結論：急な学習曲線があり、私はまだそれを学んでいます。しかし、それだけの価値はありました。とても楽しいです。
新しいアプリケーションを最初から作成する場合、WinFormsの使用は誤りです。それは基本的に投資の観点から死んでいます。 Microsoftはこれを長期間維持しますが、新しい機能や新しいサポートなどは得られません。WPFは、MSプラットフォームでの将来のデスクトップアプリケーションの明確な方向性です。
キャリアの観点から見ると、WPFとWinFormsを比較する方がはるかに優れています。上記と同じ理由で。また、Silverlightを学習するための準備が整います。これらの2つのプラットフォームの間には多くの重複があります。
そして最後に、WPFは非常に楽しいです。そしてより強力です。
学習曲線はより急です、私はあなたにそれを与えます。しかし、それは結局もっとやりがいがあります。
言及すべきもう1つの考慮事項は、 monoでのWPFサポートの計画がない があることです。 （モノ）クロスプラットフォームのサポートに関心を示さなかったと思いますが、将来的には（Winformsを使用する場合）この機会があるかもしれません。おそらく、mono（または類似の）でのWPFのサポートが実現するでしょう。
編集：私が提供したリンクが指摘し、ガルシャンのコメントが強調したように、 Moonlightは、クロスプラットフォームのSilverlightサポートを提供するために、monoチームが率いるオープンソースの取り組みです 。