WPFが生きているのはなぜですか？

長い間、私はデスクトップ用システムの開発者でした。 最初はWinFormsで、その後はより強力で柔軟なWPFでした。 それ以来、多くの時間が経過し、JSでデスクトップアプリケーションを作成する可能性について非常に多くの話があるため、WPFが終を迎えるという多くのうわさや意見があります。 また、MicrosoftはWinRTプラットフォームに新しいアプリケーションの開発を推進しています。 これは私と私の同僚を無関心にすることができませんでした。

では、GoSharp会議チーム（はい、はい、C＃についてです）が、WPFのコンテキストでデスクトップ開発に集中することにしたのは なぜですか？ 次に、フレームワークの既存の位置にある明るい瞬間と暗い瞬間、そして時間とエネルギーを投資する価値がある理由を示したいと思います。



デスクトップ開発の開発は開発中に停止したという意見があり、これにはいくつかの前提条件があります。 その1つは、WPFビジュアルフレームワークでのベース自体の停止、またはそれ以上の停滞です。 彼の重要な更新は、このように思われるかもしれませんが、約5年間ここにありません。 公式ツールキットは長い間、より正確には2010年2月以降更新されていません。 それはちょうど同じ5年です。 同時に、DevExpressやTelerikなどのカスタムコンポーネントを専門とする企業は、WPFに関するアップデートをリリースし、将来の計画を立てています。 新しい製品に焦点を当てている場合でも、WinRTのコンポーネントは、概念と一般的なXAML構造を使用しますが、これはどこにも行きません。
さらに、一部の人々がWPFを無関係と考える理由と、これらの理由の反論を提示したいと思います。

懸念の理由

懸念の理由は、1ダースで特定できます。 しかし、すべてが本当に怖くて重要なわけではありません。 主なものについて簡単に説明しましょう。

WPFチームのブログ は長い間更新されていません。

他のチームと同様に、WPFチームには独自のブログがあり、理論的にはチームの計画と成果を説明する必要があります。 残念ながら、ブログは長い間新しい情報ではありませんでした。 これは、全員が分散している、または書くことは何もないという考えにつながる可能性があります。 ただし、これはそうではなく、ブログは4か月前に更新され始め、最後のエントリは20日前に表示されました。 さらに、フレームワークの開発のためのマスタープランと、最新のCTPで利用可能な新機能の簡単な説明が登場しました。

公式のWPF ツールキットは長い間更新されていません

CodePlexの公式のWPF Toolkitページは2010年以降更新されていません。 結局、これはかつて、新しいコンポーネントで実行するためのプラットフォームであり、オープンに更新され、成功した場合はフレームワークのメインリリースにマージされました。 この状況は、新しいものを待つ必要がなく、大規模な企業からコンポーネントを購入するか、ひざの上で何かをしなければならないという疑念を引き起こす可能性があります。 しかし、 非公式のツールキットExtended WPF Toolkitは 、すべての生き物よりも活発であり、最後のリリースは2015年2月13日でした。 つまり 先週だった。 このツールキットはXceedをサポートしていますが、投資はオープンソースプロジェクトに費やされています。つまり、彼らはその背後にある未来を見ています。 バナーバナーは、このスコアに関する楽観論を明確に表しています。



さらに、最大のコンポーネント再販業者の1つである「 ベストセラー」セクションを参照すると、WPFのコンポーネントがすべての製品の売上上位5位に入っていることがわかります。

WPF認証

インターネットでは、 WPF 70-511の主要な認証は2015年に終了し、更新されないという噂と報告を見つけることができます。 リンクをクリックして自分で確認できるため、これは真実ではありません。

サポートサービスはこのコースをやや時代遅れとして認識していますが、WPF認定は引き続き有効であり、積極的に販売されています。 ただし、この認証が古くなって廃止されるという報告はありません。

Win 8+ との統合なし

WPF4のリリース中、改善の大部分はWindows 7との統合に費やされましたが、これは新しいオペレーティングシステムでは見られません。 すでにWindows 10の先端にあり、WPFのOS機能に関連する新しい機能は確認されていません。

マイクロソフトの新しい戦略

2014年2月、新しいCEOはSatya Nadelaでした 。彼は、「クラウド」部門から来ていました。 SatyaはBallmerの後任となり、Ballmerはモバイルマーケットとクラウドテクノロジーに向けて開発しようとはしませんでした。 おそらくこれが、モバイル開発とAzureのそのような進歩に対するMicrosoftの急激な動揺の理由です。 現在、同社は「クラウドとモビリティを第一に」というスローガンの下で動いています。これは、デスクトップアプリケーションの従来のモデルからの離脱とWPFの積極的な使用につながります。

Windows ストア

WPFアプリケーションをWindowsストアに公開することはできません 。 本格的なアプリケーションをダウンロードしてインストールする名刺アプリケーションを作成できますが、これは回避策のように見えます。 ただし、Microsoftは、AppleやAndroidユーザーなど、すべてのアプリケーションがストアを介してのみインストールされるという条件付き反射を作成しようとしています。 これは、WPFに対するいくつかの付加機能でもあります。

モバイル市場

これは、モバイル開発の手段として考えられたことがないため、WPFのトワイライトゾーンです。 Silverlight for Windows Phoneはこの役割を予測していましたが、誰もがこのベンチャーの運命を知っています。 現在、世界の現実は、モバイルデバイスを使用してますます多くのコンテンツを消費しており、多くが主要なプログラム用のモバイルバージョンを開発しているということです。 この場合、ほとんどの場合、WPF以外の技術のスタックを使用します。

クロスプラットフォーム

Monoの存在と開発により、クロスプラットフォームの.NETスタックについて話すことができ、ほとんどのフレームワークにはMonoのバージョンがあります。 ただし、WPF用ではありません。 この点に関する最近のソースコードの発見と熱意により、WPFは引き続きMonoに移行し、ユーザーインターフェイスプロバイダーとして機能することが可能になりました。

多くの厄介な考慮事項は、最近のマイクロソフトのアクションによって平準化または取り消されます。 そして、実際の活動のように見えますが、活動の外観ではありません。 さらに、パニックを解消してWPFを使用し続ける理由は、否定的な側面よりも多くあります。

将来のWPFの前向きな瞬間

アクティブWPFチーム

WPFチームは本当に目覚め、ブログが更新され始めました。

開発の可能性があります

WPFチームは、フレームワークのパフォーマンスを向上させ、タッチスクリーンと高密度スクリーンをサポートするために取り組んでいます。これらは現代のモバイルデバイスの特徴です。 新しいスタジオでのデバッグとプロファイリングのサポート。 グローバルプランの公開。 これはすべて励みになります。 ところで、この機会に、 WPFの将来に関するChannel9のインタビューを見ることができます。

新しいツール

人気のあるPrismツール、WPFのツールとベストプラクティスのセットがバージョン5に更新されました。次に、WPF Extended WPF Toolkitの非公式の拡張ツールキットが積極的に開発されており、数日前に更新されました。 新しいツールの開発では、DevExpressなどのフラッグシップは劣りません。

最も人気のある2つのMVVMフレームワーク、 MVVM Light ToolkitとCaliburn.Microもアクティブです。 最初のチェックは、2015年2月21日、最後のチェックは2015年3月16日です。 また、これは6か月ごとの1回のチェックインではなく、定期的な作業です。

WPFのツールのエコシステムは生き生きと進化していると言えます。これは、ビジネスにとって特に重要です。何故なら、問題が一対一に残されることはないからです。

管理の変更

2012年の終わりに、Stephen SinofskyはWindows部門の社長およびマイクロソフト全般を辞任しました。 なぜこれがWPFの良い兆候なのですか？ 彼は高貴な.NET嫌悪者として知られており、他のチームとひどく仲が良かったからです。 おそらくこれが彼の辞任の主な理由でしょう。



これは、技術的理由とともに、.Netが新しいWindowsオペレーティングシステムの主要な技術スタックとして使用されなかった理由を部分的に説明することもできますが、実際には最高のMicrosoft製品の1つです。 もちろん、外では、Stephenの噂やゴシップの忠実度と、Windows 8以降の結果に対する彼の影響を評価することは困難です。

OS市場の慣性

OS市場の慣性は良いものでも良いものでもあります。 現在、WPFに適しています。これは、 ビジネスユーザーと個人ユーザーがOSの新しいバージョンにすぐに切り替わらないためです。これにはいくつかの正当な理由があります。

企業にとって、新しいOSへの移行は常に頭痛と問題です。 すべてのサービスとそのすべての開発の互換性を検証する必要があります。 ベンダーが関連する専門家とサポートを提供できることを確認し、スタッフを準備します。 一般に、新しいOSへの移行は2年以上かかる場合があります。 このような背景に対して、2年ごとにMicrosoftがOSを含む製品の新しいバージョンをリリースするという声明は、やや奇妙で興味深いものに見えます。 たとえば、多くの企業は7から8および8.1に切り替えません。新しいバージョンでの状況と、すぐに切り替える価値があるかどうかを非常に自然に期待しています。

現在、MicrosoftのOSディストリビューションは次のようになっています。

• Windows 8 + 8.1：〜15％
• Windows 7：〜55％
• Windows Vista：〜5％
• Windows XP：〜25％

つまり WinRT関数は80％を超えるマシンでは使用できず、WPFのオプションが1つだけ残っています。 OSとアプリケーションの更新サイクルが約5年であることを考えると、週末と今後6か月間アプリケーションを作成しないことにした場合、WPFが唯一の選択肢になります。

慣性ALM

プログラムを書くのに多額の費用がかかることを知っている人はあまりいません。 まず、すべての利害関係者との一連の会議で、ビジネスプロセス全体でソフトウェアが現在のプロセスに与える影響を評価する必要があります。 主要なユーザーを見つけて、ソフトウェアの更新が必要であることを説得する必要があります。 次に、新しいソフトウェアを開発する必要がありますが、古いソフトウェアは何も起こらなかったかのように動作するはずです。 新しいアプリケーションは、古いアプリケーションと並んで動作するはずです。その結果、結果を比較して、何も欠落しておらず、すべてが少なくとも同じレベルで機能していること、さらに悪いことを理解できます。 DB部門のスタッフは、バックアップやネットワークエンジニアと協力して、ファイアウォールなどの新しいルールを構成することにも関与しています。

そして、これはプロセス全体のほんの一部にすぎませんが、これから長い間登場したばかりのテクノロジーへの応用はないことを理解するのに十分です。 WPFは専門家がいる安定したテクノロジーであり、これに基づいてプロセスを構築できるため、WPFのビジネスサポートは強力になります。 ところで、Delphi5またはFortranの専門家は、アプリケーションをサポートする必要がある場合があり、現在は非常に高価です。 一般に、それほど遠くまで行く必要はありませんが、WinFormsを使用して作成された膨大な数のアプリケーションが依然として関連しているため、WPFを削除するのは時期尚早です。

WPFの 成熟したテクノロジー

多くの開発者にとって、アプリケーションの最初のバージョンが最も時間と労力を要することは明らかです。 このように、WPF 3.0およびWPF 3.5のリリースを検討できます。 子どもの痛みを打ち負かした後、WPF 4アプリケーションはすでに「完全」になり、開発者は速度に注意を払い始めました。これは、主要な技術基盤の安定性を示唆しています。 最後に、バージョン4.5では、開発者が装飾を追加し、生産性をさらに向上させました。

技術が成熟すればするほど、必要な労力は少なくなります。 したがって、8年間の開発後、WPFサポートはほとんど必要ありません。これは成熟度を示しています。 しかし、上で書いたように、開発者はそれを放棄せず、時代の精神に従ってフレームワークを復活させることにしました。

基幹業務（LOB）アプリケーション

ローカルビジネスアプリケーションは、WPFが生き残るだけでなく、支配的になり、最良の方法でそれ自体を示す領域です。 なんで？

まず、WPFでアプリケーションを開発し、システムに展開することで豊富な経験が得られたためです。 それはそれ自体がすでに成熟した製品である.Netプラットフォームであるためです。 企業が.net上に十分なアプリケーションを持っている場合、停止して別のスタックに切り替える理由はありません。 既存のプログラマを使用して、ビジネスニーズをすべてカバーする方がはるかに簡単です。 さらに、1つのプラットフォームでのアプリケーションの統合が非常に簡単になります。

WinRTがWPFをまだ置き換えることができないもう1つの理由は、そのようなツールキットがないことです。 たとえば、NHibernateまたはEntityFrameworkの精神のORMなどは、社内アプリケーションに必要です。

多くの場合、セキュリティは、金融アプリケーションなどの基礎です。 したがって、WinRTの使用は不要であるだけでなく、お勧めできません。

WinFormsとの統合

10年以上にわたり、企業はWinForms上に膨大な数のアプリケーションを作成してきましたが、他のテクノロジーを使用してそれらを一度にリメイクすることはできません。 この場合の大きなプラスは、WinFormsとWPFが相互にコンポーネントを使用して相互に実装できることです。 したがって、あるテクノロジーから別のテクノロジーへの移行は、徐々に、比較的簡単に行うことができます。



私の知る限り、WinRTはWinFormsのコンポーネントであるフォームには実装できません。



ご覧のとおり、より多くの肯定的な側面があり、これが、WPFが忘れられず、今後も面白いタスクを求められるという楽観的な見方を私たちに与えてくれるものです。 WPFは死なず、日没になります。 現在、開発の頂点にあります。そのため、WPFを使用してビジネスアプリケーションをより適切に作成する方法と、エンタープライズユーザーインターフェイスを整理するためのベストプラクティスについて会議を開催したいと考えています。



WPFの開発にも携わっている場合、複雑なインターフェイスを作成し、複雑なビジネスドメインで作業し、デスクトップアプリケーションのベストプラクティスと傾向に関連する問題に関心があり、同僚や志を同じくする人々を見つけてすべてについて意見を交換したい場合前述- 会議へようこそ 。 私たちはお互いについて話すことがあります！

より具体的には、トピックについて説明します。

• ユーザーインターフェイスの歴史と、企業ユーザーにとってUI \ UXを便利にする方法。 窓から雲の中へ。
• 遅いゾンビアプリを作成しないでください。 Rxを使用してください！ 実際の例で。 また、TPLでは何を過小評価していましたか？
• EF番目の大きなアプリケーションは一人で住んでいますか？
• アプリケーションのプロトタイピング
• ユーザーインターフェイスで賢明なUTを記述する方法。 実際の開発経験。
• 完全な貧血領域のトピックに関するHolivar
• そして他の刺激的な物語！

サインアップ！ 3月23日まで、特別価格が有効です。