WPF対WinForms-Delphiプログラマーの視点？

私はWPFとWinFormsの主要なスレッドのほとんどを読みましたが、試行されたものと真の以前の技術（Winforms）と、その後継者（WPF）を決定するときに陥りがちな不幸なアンビバレンスに陥りました。

私は長年にわたりベテランのDelphiプログラマであり、ついにC＃へのジャンプを始めています。Delphiの仲間であるDelphiプログラマーは、Delphiで有名なAnders HejlsbergがC＃の設計者であることを知って興奮していることを理解します。DelphiのVCLカスタムコンポーネント、特にマルチコンポーネントウィザードや子コンポーネントのコンテナとして機能するコンポーネントの作成に関与するコンポーネントには強い依存症があります。

その背景から、DelphiからC＃に切り替えた皆さんが、私の最初のアプリケーションを作成するためのWinFormsとWPFの決定に役立つことを願っています。コーディングや、完全なオートコンプリートや適切なデバッガーサポートなどによってAPIの機能や呼び出しに関する情報がすぐに見つかるなど、バグの回避策を見つけることができるので、私は非常に焦ります。 。

2009年初頭のSOスレッドとコメントは、C＃UI開発コーディングを損なう可能性のあるフラストレーションの可能性に関して、WPFに大きな懸念を示しています。一方で、放棄されていなくてもすぐに交換される（WinForms）API技術を学ぶのに膨大な時間を費やすことは、同様に厄介であり、WPFの食欲をそそるGPUサポートを見つけます。

したがって、私のアンビバレンス。私はどちらの技術もまだ習得していないので、新たなスタートを切るまれな機会があり、大きな「未学習」曲線に直面する必要はありません。一方、WPFの使用がイライラしたり、私のような短気なRAD開発者に他の大きなマイナスの結果をもたらす場合は、WPFが同じレベルのサポートと使いやすさを達成するまでWinFormsを使い続けます。プログラマーとしての私の心理を具体的に示すために、私はVBを使用し、その後Delphiを使用して、初期のWindowsアプリの開発中に多くの開発者が苦労したWindows UIライブラリであるMFCによるコーディングの非常に大きな痛みを完全に回避しました。MFCを回避できたことを後悔したことはありません。

Anders HejlsbergがWPFおよび/またはWinFormsのアーキテクチャに手を携えているかどうか、そしてどちらかのコードベースで具体化された創造的なビジョンと使いやすさに不一致があるかどうかを知ることも安心です。最後に、Delphiプログラマーのために、WinFormsとは対照的にWPFを使用するとき、特にデバッガーのサポートに関して、「IDEショック」がどれだけ必要かを教えてください。2011年に更新された求人市場のコメントも歓迎します。

Delphiのバックグラウンドがある場合は、WinFormsに失望します。VCLで簡単だったことをやろうとしますが、それは痛みを伴うほど困難であるか、不可能でさえあることがわかります。WPFの制限はずっと少なくなります。

たとえば、ここで遭遇したWinFormsの制限のほんの一部を次に示します。

• WinFormsにはTActionに匹敵するものがないため、アクションでコーディングし、メニュー項目とツールバーボタンと右クリックメニューで同じテキストとアイコンを共有し、有効化ロジックを集中化し、有効化状態を更新することに慣れている場合OnUpdateを使用してバックグラウンドで... WinFormsを嫌いになります。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はいくつかの重要なコントロールでオーナー描画を省略しますが、代わりにWPFを使用している場合、オーナー描画は必要ありません-TreeViewノードに黒のテキストと括弧内の青い数字が必要な場合は、それをDataTemplateに入れれば動作します。ownerい所有者描画コードは必要ありません。
• サードパーティのコントロールが必要ですか？多くの場合、WinFormsの方法でそこにあるものを拡張することができ、VCL開発者は夢見ることしかできないので、それらは必要ありません。

WPFには非常に急な学習曲線がありますが、良い本（例： " WPF 4 Unleashed "）を選択すれば、最悪の事態を乗り越える助けになります。 WinFormsのようにあなたを妨げません。

私は通常、WPFの良い経験がなかったと言っている人々に非常に驚いています。私は、C ++ / MFCからC＃/ WinFormsからC＃/ WPFに切り替えた開発者です。WinFormsからWPFへの移行は簡単ではありませんでした。XAMLの学習はそれほど簡単ではありませんが、一度習得すれば、それは素晴らしいテクノロジーです。私にとっては、WinFormsに戻ることはできません。WPFは最高です。

私を悩ますもう1つのことは、人々が通常WPFをUIだけと関連付ける方法です。私の意見では、UI設計の容易さの点では、WinFormsよりも100倍優れていますが、WPFを使用したい理由は他にもたくさんあります。

1. もちろん、UI。
2. バインディング。ただの魔法。UIに続く最も強力な機能。LOBアプリケーションは、これから最も恩恵を受けます。
3. コマンド。
4. 関心事の分離。設計者は設計に取り組み、プログラマーはプログラムを作成します。
5. 添付プロパティ。ソースコードなしでサードパーティのコントロールの機能を拡張できます（ただし、この点は最初の点の一部になる可能性があります）。
6. Silverlightへの簡単な移行（WebとWP7の両方）

あなたがWPFを学ぶ理由として最後の点について私に同意しないかもしれませんが、あなたが私に尋ねるなら、それは最大の1つです。WPFを学習すると、Silverlightに簡単に移行できます。Silverlightは大きく成長しており、素晴らしい技術でもあります。

そして最大の理由は、それが未来だということです。Silverlightと統合される可能性がありますが、スキルは変わりません。

だから、私はあなたにWPFの道を行くことを強くアドバイスします。

明らかに、WPFは、将来の思考方法です。それをマスターするのは難しいですが、プラットフォームは非常にうまく設計されており、柔軟です。

数行のアドバイス：

• 簡単に始めましょう：MVVMまたはファンシーアニメーションのみを使用して最初のプロジェクトを実装しようとしないでください。ウィンドウ、ボタン、リストで簡単に始めましょう。
• DataBindingを活用してください。
• Adam NathanのWPF Unleashedという本を購入します。

私は以前に多くのwinformsを使用したことがありますが、私は主にasp.net開発者であることに最初に注意する必要があります。WPFへの切り替えは、1週間ほど（40時間以上）した後（40分以上）行ったほど大きくありません。ほとんどが再び2番目の性質でした。

とにかく、少なくともこの本の出版社によれば、Anders HejlsbergはWPFの背後にいる建築家の一人だと信じています->

「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は、物事が進む方向です。（ゴージャス！）VS2010 UIは、Winformsで構築された以前の世代とは異なり、WPFベースであると言われています。

快適なゾーンに滞在したい場合は、winformsを使用してください。最新かつ最高のものに追いつくには、WPFに没頭してください。

私はDelphiプログラマーではありませんが、はい、WinForm（重度）とWPF（中程度未満）の両方に取り組んできました。WinFormからWPFに切り替えようとしている人のフラストレーションレベルについては、ある程度慣れていますが、慣れるまでは同意します。WPFの優れた柔軟性とWinFormとの比較をご覧ください。少なくともDelphiのバックグラウンドから来た人で、Winformではない人にとっては、学習曲線が重いです。あなたにとって、それは間違いなくWinFormではなくWPFに移行する価値があり、その価値はあります。

次のリンクを調べて開始することをお勧めします。

• http://drwpf.com/blog/
• http://www.wpftutorial.net/
• http://joshsmithonwpf.wordpress.com/

私はいくつかのWindows Formsの作業（ほとんどがPocket PC上）に加えて、同じ原則を使用した他の非.NET環境を実行しました。約3年前にWPFに移行したとき、最初の数か月間はそれを誓っていました。最終的に「クリック」されただけで、振り返ることはありません。実際、次のプロジェクトでWindows Formsに戻る必要があった場合は困ります。

Windows Formsが最後に更新されたのは2005年（VS 2005）でした。それはまだありますが、Microsoftによって改善されていません。WPFは、デスクトップアプリの新製品です。したがって、MSツールを使用して.NETプラットフォームに移行する場合は、安全な方法だと思います。Silverlightをデスクトップソリューションとして推進している人もいますが、可能性として考えたとき、制限が多すぎることがわかりました（Webコンテキストでは意味がありますが、デスクトップではあまり意味がありません）。

結論：急な学習曲線があり、私はまだそれを学んでいます。しかし、それだけの価値がありました。とても楽しいです。

新しいアプリケーションをゼロから作成する場合、WinFormsの使用は間違いです。基本的に投資の観点からは死んでいます。マイクロソフトはしばらくそれを維持しますが、新しい機能や新しいサポートなどは得られません。WPFは、MSプラットフォームでの将来のデスクトップアプリケーションの明確な方向性です。

キャリアの観点からは、WPFとWinFormsを知っている方がはるかに優れています。上記と同じ理由で。また、Silverlightの学習についても十分に理解してください。これら2つのプラットフォームの間には、かなりの重複があります。

そして最後に、WPFは単純にもっと楽しいものです。より強力です。

学習曲線は急です、私はあなたにそれを与えます。しかし、最終的にはよりやりがいがあります。

言及すべき追加の考慮事項の1つは、monoでのWPFサポートの計画がないことです。（モノの）クロスプラットフォームサポートに興味はなかったと思いますが、将来（Winformsを使用する場合）この機会が得られる可能性があります。おそらく、モノラル（または同様の）でのWPFのサポートが登場するでしょう。

編集：私が提供したリンクが指摘し、Gulshanのコメントが強調したように、Moonlightは、クロスプラットフォームのSilverlightサポートを提供するために、モノチームが率いるオープンソースの取り組みです。

WPFのことを聞いたとき、興奮しました。アイデアは素晴らしく聞こえ、私が見たものはすべて美しいものでした。ただし、Visual Studio 2008（確かにベータ版）で使用するようになったとき、デザイナー/ IDEで作業するのはイライラし、風変わりです。

当時、私のブログに少し情報を投稿しました：
http : //blog.dantup.com/2007/08/visual-studio-2008-beta-2-first.html
http://blog.dantup.com/2007 /08/wpf-designer-cider-part-2.html

2010年には試したことはありませんが、いくつかの人に話を聞いたことがありますが、まだ理解するのが少し複雑で面倒なようです。

あなたのアプリケーションは間違いなくWPFで見た目や雰囲気が良くなると思いますが、ビルドに時間がかかり、途中で頭を大きく叩くと思います。