1

かなりリッチなクライアント インターフェイスを必要とする新しい Windows アプリケーションの設計を開始していますが、どのクライアント API を使用すればよいかわかりません (WPF、Silverlight、WinRT、HTML5 など)。人々がこの決定を下すのに役立つMSからのガイダンスがほとんどないことに、私は実際にはかなり不安を感じています.

さまざまなクライアント API に対する MS のサポート戦略は? それぞれの寿命は？私は、現在既知でサポートされている API (WinForms または WPF) で完全なクライアント アプリケーションを作成して、MS が 2 年以内にそのサポートを取り下げ、それを書き直すことを余儀なくされることは望んでいません。しかし、大規模な企業展開が少なくとも2年間は行われないため、WinRTで書くことは本当にできません. では、代わりに Silverlight のような Web ベースのアプローチを使用する必要がありますか? そのサポート/長寿の話は何ですか? 代わりに HTML5 に移行しますか? 私がその道を行く場合、オープン ソース スタックだけでなく Microsoft スタックを使用する利点は何ですか?

ここで合計 22 のキャッチがあるように感じますが、Microsoft からの適切なガイダンスが見つかりません。物事の音から、WPF でソフトウェアを作成するのはばかげているでしょう (すぐに?) がドロップされるためですが、企業が数年間展開しないため、WinRT で作成することはできません。このすべてが、私には完全に狂ったように感じます。

考えやアイデア？

4

1 に答える 1

2

あなたの経験と、あなたが「Windowsアプリケーション」（Webアプリケーションではない）と言ったという事実を考慮すると、私は間違いなくWPFに行きます。基になる API の別のセットを使用する場合でも、WinRT は XAML、バインディング、スタイル、トリガー、DataTemplates などの WPF のコア概念を維持することに注意してください。したがって、WPF から WinRT にコードをコピーして F5 キーを押すことができないのは事実ですが、これらのテクノロジ (つまり、ビューに依存しない ViewModel) 間で互換性のある作業がかなりの量ありますが、HTML、Winforms、およびその他のフレームワークは物事を行う方法がまったく異なり、作業には異なる考え方が必要です。

マイクロソフトが何をするかに関して..私はあまり心配していません.VB6のような古い技術でさえ、OSの現在のバージョンでまだ「実行可能」のままであるという証拠があり、私はそうする必要があるとは思わない. Metro が標準になっても、2 年でアプリケーション全体を書き直します。Metro は、従来のデスクトップ アプリケーションを置き換えることはできません。従来のデスクトップ アプリケーションは、依然としてデータ集約型アプリケーションにとって最良の選択肢であることが証明されています。

そして、私たち全員が実際に WinRT を使用するようになるときが来たら、HTML や winform を作成した人よりも、MVVM と XAML を使用して既に記述された SL / WPF アプリケーションを作成した人の方がはるかに簡単になります。

最終的に何を選択するにしても、アプリケーションの機能を UI からできるだけ分離するようにしてください。これにより、UI フレームワークの変更が必要な場合に非常に簡単になります。

あくまでも個人的な意見ですので、他の方の意見もお聞きしたいです。

編集:もう1つの非常に重要な側面は、アニメーションを多用するUIを実際に作成する必要がある場合、または従来の戦艦のような灰色のUIから一歩離れる必要がある場合、これまたはHTML/ WPF / SL / WinRT で 3 行の XAML を必要とすることを実現するためにこれらのテクノロジで必要なコードの量は言うまでもなく、すべてのブラウザーが異なる方法でレンダリングする Javascript 地獄です。

于 2012-11-12T20:40:50.370 に答える