私は、開発者チームが既存の10歳のシステムを置き換えるための非常に長期的なインフラストラクチャプロジェクトを構築しているプロジェクトに携わっています。 「非常に長期的に」とは、リリース時点から少なくとも10年間は運用、サポート、維持されていなければならないということです。 〜2年間の開発を考慮すると、この時点で少なくとも12年間続くテクノロジー/言語/フレームワークを選択する必要があります。私たちは、プロジェクトを実行しているコンピュータやそのオペレーティングシステムなどを完全に制御しています。私は、置き換えられる10歳のシステムの開発者でした。私はチームが新しいものを構築するのを手伝っています。超長期プロジェクト用にWPFでC＃を選択するには？
アプリケーションには非常に複雑なユーザーインターフェイスがあります。 UIは起動時に設定ファイルから動的に構築され、各UIコンポーネントはロジックやその他のUIコンポーネントに依存しており、実行時に受け取らなければなりません。
- それは次のようになります。UI要素自体は
つの選択肢は、すでに私は判断または変更しようとしないことが、このプロジェクトで行われている非常に複雑な、カスタムゲージを想像して、グラフ、ノブなどですデスクトップアプリケーションは
- それは
は、今、私たちは、私たちの非常に柔軟なUIシステムは「開発が容易な」作るすなわち依存することにより、開発者のバグの数を減らすために右のフレームワークを選択するポイントであるC＃で開発されます既に作成されたデバッグ済みのフレームワークで
チームは、その目的に非常によく合ったMicrosoftのCAB（Composite UI）を調べましたが、2007年にMicrosoftが中止したという事実は、プロジェクトの長期的な側面を考慮に入れると大きな問題になります6年間で発見されています - 誰がサポートを提供するのですか？ - 私はコードをCAB自体に修正することができますが、これは避けたいものです）。
明白に浮かべていることの1つは、MicrosoftのWPFに依存していることです。それはUI開発の "未来"のようですが、長期的に考えると驚いています。私の主な関心事は、市場がそれを受け入れないということです.3年後にマイクロソフトはそれを中止し、6年後、私はそれを適切にサポートすることができなくなるでしょう。
しかし、自分のフレームワークを書いているのに加えて、私は本当に代替手段を見ていません。私は第三者のフレームワーク開発者を無視したくないのですが、このような長期的なプロジェクトでは、非常によく確立されたベンダーの製品/フレームワーク/などしか使用できません。
WPFを選択することは、上記の文脈で与えられた適切な呼び出しであるかどうかを考えていただきたいと思います。もしそうでなければ、C＃を使ったこのような長期的なデスクトップアプリケーションプロジェクトのための正しい「複雑なUIフレームワーク」は何ですか？
ありがとうございます（長い質問のため申し訳ありません）
有益な回答ありがとうございます。あなたの冗談について - ソフトウェアやハードウェアのベンダーが2〜3年ごとにアップグレードを進めるペースで、10年先の計画を立てることはほとんど不可能だと私は思っています... –
"Silverlight（Microsoftが本当に気にしている）" 5年後、この見積もりは面白いです... – Yaurthek