Windowsフォームに関するほとんどの制限とトリックは、ほとんどのプログラマーに共通しています。ただし、.NET 3.0以降、WPF、WindowsPresentationFoundationも利用できます。これを使用すると、「セクシーなアプリケーション」をより簡単に作成できると言われています。.NET3.5 SP1を使用すると、実行速度が大幅に向上します。
しかし一方で、WPFでは多くのことが異なって機能しています。これ以上難しいとは言いませんが、「すべて」を一から学ぶ必要があります。
私の質問：新しいGUIを作成する必要があり、プロジェクトに時間のプレッシャーがない場合、この余分な時間を費やす価値はありますか？
私は、顧客のコア システムになった WPF を使用して 7 か月になります。WPF を学び、基幹業務のプレゼンテーション プラットフォームとして使用した経験について、もう少し考えを共有したいと思います。
一般に、上記のコメントは今でも有効です... WPF の設計時のサポートはまだありません。急いでリッチ クライアント アプリケーションをすぐに使えるようにする場合は、Windows フォームを使用してください。限目。Microsoft は、GDI/Windows フォーム プラットフォームの廃止を急いでいるわけではないので、将来にわたって適切なサポートを期待できます。
WPF をマスターするのは簡単ではありませんが、WPF の学習に時間とエネルギーを投資するかどうかについて、それで決定を下すべきではありません。現在は成熟度に欠けていますが、WPF はいくつかの便利で最新の概念に基づいて構築されています。
たとえば、WPF では、適切な検証ロジックを備えた適切に作成されたビジネス オブジェクトへの投資は、堅実な投資です。Windows フォームとは異なり、WPF のデータ バインディングには、GUI コードを記述してエラーを検出することなく、インターフェイス コントロールが無効なユーザー入力に反応できるようにする機能が豊富にあります。これは貴重です。
WPF のスタイリングおよびテンプレート機能も価値があることが証明されています。スタイル設定とテンプレート化の唯一の用途は画面上のアイキャンディーを作成することであるという一般的な誤解にもかかわらず、真実は、これらの機能が豊富なフィードバックを提供するユーザー インターフェイスのコーディングを大幅に簡素化することです。基になるビジネス ロジック レイヤーの状態、またはカーソル下のオブジェクトの状態に基づいてテキストをインテリジェントに検索するツールヒントなど。
これらはすべて、基礎となるデータとインターフェイスを一致させ続けることを容易にするという理由だけで、「何も凝っていない」ビジネス アプリケーションにとって信じられないほど価値のある機能になります。
手短に：
一見微妙な違いですが、コードを再利用する能力に大きな違いをもたらします...これは、「Windows フォームと WPF の問題は実際には投資決定ですか?」という疑問を投げかけます。
（これは私のお気に入りのスレッドになったようです。）
WPFを使用するやむを得ない理由はありますか
絶対！WPFは絶対に素晴らしいです！これは、Windowsフォームに欠けている非常に多くの機能と機能を備えているため、実質的にすべてのプロジェクトにとって大きなメリットになります。
ビジネスアプリケーションの場合、最大のメリットは次のとおりです。
ユーティリティとゲームの場合、他の利点が前面に出てきます。
要するに、Windowsフォームで構築できるかなりのサイズのGUIは、3分の1の労力（またはそれ以下）でWPFに構築でき、見た目もはるかに良くなります。
WPFはより多くのリソース（特にRAM）を必要としますか
Windowsフォームに比べて料金はかかりますが、少額です。
CPUの使用に関するもう1つの注意事項：アニメーションと変換（モーション、変換など）は、保持モードストレージがあるため、実際にはWindowsフォームよりもWPFの方が効率的です。遅いのは、そこにあるオブジェクトの最初の取得です。
メンテナンスのオーバーヘッド
WPFは、メンテナンスに関してWindowsフォームよりも大きなメリットがあります。すべてが以前の1/5のコードで行われるため、維持するコードは1/5になります。さらに、ボイラープレートのすべてがなくなったので、実際に作業を行うコードに集中できます。
XAMLの利点
XAMLはWPFのコアです。WPFはXAMLなしで使用できますが、XAMLを使用すると非常に使いやすくなります。XAMLにはユーザーインターフェイスを簡単に指定するHTMLの機能がありますが、組み込みのタグははるかに強力であり、独自のタグを簡単に定義できます。（実際、そうするのは正常です）。
XAMLのいくつかの特定の利点：
その他の洞察
私は何年もの間、WPFのようなものを夢見ていました。多くの人がこの機能の一部を実装していますが、すべてを1か所にまとめてこのような価格（$ 0）で入手できるのは素晴らしいことです。
WPFは、Windowsフォームからの大きなパラダイムシフトであり、慣れるまでに時間がかかりますが、WPFの学習に費やす時間は、何倍もの利益をもたらします。
WPFには、5年経ってもまだいくつかの疣贅がありますが、一度経験すると、その力は完全にあなたを吹き飛ばします。誰かがあなたをWindowsフォームに引き戻そうとすると、あなたは蹴ったり叫んだりするだけです。
ヒント：-開発用にExpressionBlendのコピーを入手してください-時々XAMLを手動で編集してください-最初は奇妙に思えても諦めないでください
WPF を使用すると、いくつかの驚くべきことが可能になります。私はそれが大好きです...しかし、開発者から新しいテクノロジに移行する必要があるかどうかを尋ねられるたびに、私は常に自分の推奨事項を修飾する義務があると感じています。
開発者は、WPF を効果的に使用する方法を学習するために必要な時間を (できれば熱心に) 費やしても構わないと思っていますか? MFC、Windows フォーム、または管理されていない DirectX についてこれを言うとは思わなかったでしょうが、通常の開発の過程でチームが WPF を「ピックアップ」しようとすることはおそらく望まないでしょう。配送商品のサイクル！
開発者の少なくとも 1 人または 2 人がある程度のデザイン感覚を持っているか、また最終的なデザイン権限を持つ個人が開発の問題を十分に理解しているかどうか。WPF 機能を活用して、単なる「カラフル」ではなく、実際により良いものを作成できますか? 、無償のアニメーションをフィーチャー？
対象となる顧客ベースの何割かは、計画していた機能をサポートしていない可能性のある統合グラフィックス チップ セットを使用していますか? それとも、まだ Windows 2000 を実行しているので、顧客として完全に排除されますか? 顧客は実際に強化されたビジュアルを気にかけているのかと尋ねる人もいますが、1990 年代初頭の社内での「私たちのビジネス顧客は色や写真を気にしない」という議論を経験してきた私は、競合他社の適切に設計されたソリューションが、本当の問題は、彼らが今すぐ気にかけるようなものをあなたが提供できるようにするための条件が正しいかどうかです。
互換性のない従来の足場にフックしようとする複雑さが増すのを避けるために、プロジェクトには少なくともプレゼンテーション層の基礎開発が含まれていますか (Win フォームとの相互運用はシームレスではありません)。
あなたのマネージャーは、開発者の生産性が 4 か月から 6 か月間大幅に低下することを受け入れることができますか (または気付かないように気を散らすことができますか)?
この最後の問題は、WPF の "FizzBin" の性質として私が考えるのが好きなものによるものです。タスクを実装するための 10 の異なる方法があり、1 つのアプローチを別のアプローチより優先する明確な理由はありません。選択。どのような選択をしたとしても、その欠点が明らかになるのはプロジェクトのずっと後の段階になるだけでなく、プロジェクトのすべての開発者が異なるアプローチを採用することが事実上保証され、その結果、大きなメンテナンスの頭痛の種になります。最もイライラするのは、フレームワークを学ぼうとするときに常につまずく矛盾です。
私のブログのエントリで、WPF 関連のより詳細な情報を見つけることができます。
WPF には Windows Vista または Windows XP SP2 が必要ですが、これは面倒な要件ではありませんが、関連する要件です。Windows 2000 で実行したい場合 (一部の人はまだ実行しています)、WPF は機能しません。
WPF も新しいテクノロジであり、Windows フォームほど証明されていないため、特に大規模なアプリケーションの場合、リスクの少ないオプションとして Windows フォームを選択できます。
そうは言っても、はい、WPFは未来です。Visual Studio 2010 は WPF で書き直されています。これはおそらくこれまでで最大の WPF アプリケーションであり、テクノロジの真のテストにもなります。
明らかに、レガシ Windows フォーム アプリケーションは、それが正しい選択である別の状況です。
他の方もおっしゃっていますが、どちらに行ってもメリットとデメリットがあります。他の人が言ったように、WPFの利点は次のとおりです。
ただし、WPF には欠点があり、Windows フォームが優先されます。
最後に、作業を行う (または適切なサードパーティ ツールを使用する) 場合、どちらのツールでも優れた魅力的で魅力的な UI を作成できることを覚えておいてください。結局のところ、すべての状況でどちらが優れているとは限りません。プロジェクトに適していると思われるものを使用してください。
WPF のプログラミング モデルは、Windows フォームよりもオープンで柔軟ですが、ASP.NET MVC と同様に、Model-View-ViewModel パターンを正しく実装するという点で、もう少し規律が必要です。
WPF を使用した最初のLOBアプリケーションは完全な失敗に終わりました。これは、エンド ユーザーの非常にローエンドのラップトップの粉砕を停止させるリソースの浪費だったからです。 LINQ to SQLと良い結果が期待されます...そして、これは WPF が Windows フォームから非常に大きく異なる場所です... Windows フォームでは、そのようなことを回避できます。WPF は、Windows フォームよりもはるかに多くのリソースを必要とします。アプリケーションを無駄のない設計にしないと、800 ポンドのゴリラになってしまいます。
WPF をためらわないでください...調べてみてください。ただし、Windows フォーム コーディングの許容できる欠点は、WPF で良い結果を生まないことに注意してください。これらは根本的に異なるエンジンであり、根本的に異なるコーディング パターンに対応しています。
最後に: WPF を使用する場合は、リストとグリッドで使用するデータ仮想化についてよく理解してください。単純なデータ バインドされた ListItem または GridCell とは、WPF では膨大な論理的および視覚的なオブジェクト グラフになってしまいます。仮想化の方法を学ばなければ、アプリケーションは大規模なデータ セットでうまく機能しません。
WPF には非常に急な学習曲線があり、まず明らかな本 ( Adam Nathan、 Sells/Griffiths、および Chris Anderson ) とブログ ( Josh Smithなど) を入手することをお勧めします。それに備えて、プロジェクトで WPF を学習する時間を確保してください。
テクノロジの学習に加えて、WPF アプリケーションの構築に使用されるパターンの学習にも時間を費やしてください。Model View ViewModel (MVVM) は、広く受け入れられているもののようです。
個人的には、WPF は価値があると思いますが、あらかじめご了承ください。また、ユーザーを Windows XP SP2+ および Windows Vista に効果的に制限していることにも注意してください。Google ではそのように決定しましたが、要件が異なる場合があります。
どちらのテクノロジーにも長所と短所があります。「クラシック」UI を備えた大規模なアプリケーションでは、Windows フォームを使用します。豊富なユーザー インターフェイス (スキニング、アニメーション、ユーザー インターフェイスの変更) を必要とするアプリケーションでは、WPF を選択します。WPF と Windowsフォームを比較する WPF と Windows フォームの記事を確認してください。
UIデザインの柔軟性に加えて、WPFにはいくつかの技術的な利点があります。
1.）WPFはGDIオブジェクトに依存しません。 そうですね、ウィンドウ自体のインスタンスに2つのGDIオブジェクトを使用していると思いますが、実際には何もありません。私は、非常に大規模な内部Windowsフォームアプリケーションにある程度関わってきました。私たちのオフィスの人々は時々それの3つまたは4つのインスタンスを同時に実行します。問題は、Windows 2000、XP、およびVistaに固有の10,000GDIオブジェクトの制限に頻繁に遭遇することです。これが発生すると、OS全体が応答しなくなり、視覚的なアーティファクトが表示されるようになります。それをクリアする唯一の方法は、アプリケーションを閉じることです。
2.）WPFはGPUを利用します。 WPFがUI処理の一部をGPUにオフロードする機能は素晴らしいです。私はそれのこの側面が時間とともに良くなることを期待しているだけです。元OpenGLプログラミング愛好家として、GPUからもたらされるパワーを高く評価することができます。つまり、私の100ドルのビデオカードには、それぞれ1.5 GHzで動作する112個のコアがあります（これは決して最上位ではありません）。この種の並列処理能力は、クアッドコアCPUを恥ずべきものにする可能性があります。
ただし、WPFはまだかなり新しいものです。Windows 2000では実行されません。実際、WPFアプリケーションは、再起動後に起動が遅くなる可能性があります。私は私のブログでこれらすべてについて話します：http： //blog.bucketsoft.com/2009/05/wpf-is-like-fat-super-hero.html
WPFを学ぶ価値があると思います。スピードが上がると、フォームのデザイン作業がはるかに簡単になります。私は「セクシーな」ものについてはそれほど心配しません。これのほとんどは単なる流行です。WPFでは、「通常の」Winformsスタイルのアプリケーションを非常にすばやく簡単に作成できます。
全体のコンセプトは、IMOの設計を容易にするのに役立ちます。
ここでの回答のいくつかには同意しません。WPF は、基幹業務(LOB) アプリケーションに非常に適しています。(フロッグ デザインの LOB クライアントが最適な例です)。また、UI を魅力的なものにするすべての可能性 (ビジネス アプリケーションでは必要ありません) に加えて、WPF はさらに多くの機能を提供します。
データ バインディングとテンプレート機能は、Windows フォームより優れています。また、コードとプレゼンテーションを分離するためのはるかに優れた方法も提供します。開発者が 2 ～ 3 人以下のチームで、2 つの LOB アプリケーションに WPF を使用することに成功しました。
直面する最大の問題は、WPF に慣れていない開発者にとって開発速度が低下する (Windows フォームと比較して) おそらく WPF の学習曲線が急であることです。
現在、Windows フォームから WPF でアプリケーションを書き直しています。はい、急な学習曲線があり、いくつかのことを「再学習」する必要がありますが、それだけの価値があります. また、WCF と組み合わせることで、以前よりも少ないコードで、より高速に、より堅牢に記述できるようになりました。
しばらくそれを使い続け、Adam Nathan の本を読み、 TelerikやComponentOneなどのサードパーティ製コントロールの増え続けるライブラリをチェックしてください。私の見解では、1 つのマイナス点は、デザイン ツールのExpression Blendが非常に使いにくいことです。最新バージョンはまだベータ版ですが、Visual Studio を何年も使用してきた私たちにとっては適切ではありません。はい、主にデザイナー向けですが、Visual Studio ではできないことがいくつかあります。
WPF はより優れた UI エクスペリエンスを提供できるため、インターフェイスの設計が重要な場合は WPF を検討してください。しかし、Windows フォームは何年にもわたる進化を続けてきたため、機能することが証明されており、そのプラットフォームに精通した多くのプログラマーを見つけることができます。
また、移植性も問題になる可能性があります。WPF は Windows XP SP2 以降でのみ動作します。
また、WPF の学習曲線は急勾配であるため、特定の WPF の経験がなければ高品質の製品を提供することは容易ではありません。
WPFは.NET3.0の一部であるため、1つの答えは「1.1または2.0をサポートする必要がある場合」です。WPFには既知のOSの制限があり、明らかなスキルの問題があります。winformsを知っている開発者のチームがある場合、winformsを使用して堅牢なコードを作成する方が簡単な場合があります。ただし、多くのUIコードを記述している場合は、ある時点でWPFを取得し始める価値があります。
WPFもSilverlightと多くの共通点があるため、転送可能な利点があります。
WPF には、優れたデータ バインディング機能、関心の分離、設計とロジックの分離など、多くの利点があります。
開発者として、私は Windows フォーム デザイナーに縛られるのではなく、XAML を使用して UI を定義できることを楽しんでおり、アプリの見栄えを良くするために別のデザイナーに頼ることができると知って安心しています。
個人的には、古いバージョンの Windows がサポートされていないことは気にしませんが、WPF の大きな問題の 1 つは、Mono ( http://www.mono-project.com ) で (現在/これまでに) サポートされていないため、WPFです。アプリは Mac OS または Linux では動作しません。(ただし、Silverlight アプリケーションはそうします)。
WPF の学習に投資する時間とリソースがある場合は、それを実行してください。複数の OS をサポートする Silverlight アプリケーションを作成する場合でも。
SWF を使用して複数の OS スティックでデスクトップ アプリケーションを実行する必要がある場合。
多くの違いがあります。私たちは次の点で WPF を愛用しています。
ただし、次の理由により、Windows フォームに固執しました。
どちらを使用するかを決定する際の最大の考慮事項は、対象ユーザーがどの .NET Framework をインストールしているかを考慮することです。Windows フォームのみをサポートする下位の .NET Framework バージョンを使用しているユーザーが増えていることがわかりましたが、これは私の個人的な経験にすぎません。
WPFを使用すると、フォームの設計作業を、デザイナーの服の開発者ではなく、実際のデザイナーに簡単に渡すことができます。それがあなたのやりたいことなら、WPFがあなたの答えです。従来のWindowsスタイルのボタンで問題がない場合は、Windowsフォームが最適です。
（複数の回答から、インターフェイス設計が「重要」である場合はWPFを使用する必要があると主張されていますが、それはかなりあいまいです。インターフェイス設計は常に「重要」です。）
WPF の利点は、カスタム コントロールとアニメーションを使用して見栄えの良い GUI を簡単に作成できることです。WPF は、プレゼンテーション層とロジック層をさらに分離するのにも役立ちます。デザイナーがいる場合、この作業の 95% を非コーダーに任せることができ、コーダーはロジックに取り組むことができます。欠点は、Expressions Blend のソフトウェア コストと、XAML をレンダリングしようとする際にフレームワークの呼び出しに巻き込まれる傾向があるため、適切に機能する Visual Studio コード プロファイリング ツールがないことです。他にもあると思いますが、実際に見たのはこの2つだけでした。
主な考慮事項は、顧客に .NET 3.0 またはそれ以上の .NET 3.5 SP1 をインストールするよう要求する場合です。否定的なフィードバックが返ってきます
MSDN ライセンスをお持ちの場合は、Expression toolsを確認してください。WPF 用に明示的に設計されており、Visual Studio に直接エクスポートできるため、移行が容易になります。
WPFでのテキストレンダリングには既知の問題があります。多くのユーザーは、アンチエイリアシングとピクセルブレンディングを多用するとテキストがぼやけると報告しています。これは、状況によっては大きな問題であり、私が知る限り、Microsoftはある程度のレベルで認めています。
DotNetRocksエピソード315で、BrianNoyesはこれについて広範囲に説明しています。
Windowsのサポートのみに関心があり、Windowsの学習にかかる時間を気にしない場合は、WPFを使用してください。高速で柔軟性があり、スキンの変更が簡単で、操作するための優れたツールがあります。
過去 3 年半の間、私は (2 つの会社で) Windows フォームの開発を行ってきました。どちらのアプリケーションも広範囲に使用され、最終的に GDI の問題が発生しました。大規模な Windows フォーム アプリケーションは最終的に GDI リソースを使い果たし、エンド ユーザーは再起動する必要があります。
上記の回答で既に説明されている長所と短所を考慮して、WPF を使用することにした場合は、このdnrTV エピソードをビリー ホリスと一緒に読むことを強くお勧めします。
副次的なボーナスとして、Silverlight は WPF に基づいており、どちらから始めても、もう一方を操作するためのノウハウを得ることができます。物事が Web ベースに移行し続ける場合、ブラウザ (または Windows Live Mesh) に簡単に転送できる予備知識 (および既存のコードのライブラリ) があれば、ソフトウェアの寿命を延ばすことができます。
Mark の以前の投稿からの引用:
- Windows フォームでは、ユーザー インターフェイスを設計してから、そのユーザー インターフェイスを操作するコードを記述します。これには通常、データ オブジェクトを操作するコードも含まれます。
- WPF では、データ オブジェクトを駆動するビジネス層に投資してから、データ オブジェクトをリッスンするインターフェイスを設計します。
これは、Windows フォームまたは WPF を使用しているかどうかではなく、設計上の選択であると私は主張します。ただし、特定のテクノロジーが特定のアプローチにより適している可能性があることは理解できます。
Scott は、Expression Blend について不満を漏らしており、それが開発者としての彼にとってどのように意味をなさないかについて述べています。Expression Blend に対する私の最初の反応はそのようなものでした。しかし、今では非常に貴重なツールだと思いますが、実際には開発者のタイプによって異なります。
私はインテグレーターの役割を果たさなければならなかったユーザー インターフェイス開発者であり、最終的に、スタイルを作成し、テンプレートを WYSIWYG 方式で制御するのに Expression Blend が非常に貴重であることがわかりました。ほとんどの場合、Expression Blend と Visual Studio を同じプロジェクトで同時に実行しています。
また、Expression Blend で遊んで、吐き出されるXAMLを調べることは、WPF API を学習するための優れた方法だと思います... Windows フォームでデザイナーを使用し、吐き出される C# コードを確認するのと同じように、役に立ちます。そこでデザインしているものをどのように使用するかを学びます。
Expression Blend が役立ちます。特にアプリケーションのビジュアルに取り組んでいる場合は、試してみてください。
WPF は、XAML、豊富なコントロール テンプレートとスタイル設定、およびExpression Blendなどのツールを介した宣言型 UI のサポートにより、デザイナーが同じプロジェクトで開発者と共同作業することを大幅に改善します。さらに、開発者は、添付された依存関係プロパティと非常に強力なデータバインディングの柔軟性を得ることができます。さらに、Silverlight は XAML のサブセットと WPF と同じコントロール クラスをサポートしているため、最小限の労力でアプリケーションをRIAとして移植できます。
私はいつでも Windows フォームよりも WPF を選びます。ターゲット マシンに.NET 2.0しかない場合でも、ユーザーが追加のプログラムをインストールできる場合、新しい .NET Framework クライアント プロファイルを使用すると、WPF アプリケーションの展開が非常に簡単になります。
私が Windows フォームに固執する唯一の理由は、.NET 2.0 または .NET 1.1 しかインストールされていないロックダウンされたマシンに製品が展開される場合です。
WPFの専門知識がなく、それに投資したくない場合のみ:)
Winforms は、実際のアプリケーションにとってはひどいものですが、「Visual Basic 6.0」スタイルのラピッド プロトタイピングには非常に適しているため、概念の迅速な証明に Winforms を使用します。
したがって、ここに例を示します。
プロセスの複数のステップ (何かのダウンロード、計算/変換、インテリジェントな出力の作成など) を追跡し、すべてを再現可能にする必要がある場合は、通常、ListBox といくつかのボタンを備えた簡単なフォームを作成します。
私は REAL 開発者なので、とにかくロジックはビュー以外のクラスに既にあるので、ここから始めるのがよいでしょう。
WPF を使用すると、アプリケーションを大幅にカスタマイズする手段が提供されます。非常に迅速にコーディングできます。つまり、テキスト ボックスのようなカスタマイズ コントロールを数秒で作成し、コンテンツ スタイルなどのさまざまな属性をカスタマイズできます。最良の部分は、UI の美しさ、つまりアニメーション、トリガーなど、グラフィックです。ただし、適切なハードウェア仕様と、Windows Vista および Windows 7 でのみ使用できるいくつかの特別な機能が必要です。
Windows フォームには、実際に重要なこれらの豊富な機能がありません。それ以外の場合は、WPF でできるように、それを使用してあらゆる種類のアプリケーションを作成できます。
Windows フォームと WPF はまったく別物であり、プロジェクトの要件、つまりクライアントまたはユーザーが何を望んでいるかによって異なります。
( Visual Basic 6.0からの) 変換プロジェクトの場合、チームを WPF に切り替えるのは困難です。学習曲線に加えて、人々はすでに古いインターフェースに慣れています。Windows フォームは、段階的に廃止されますが、まだ長い間使用されます。