Windows 8用のエンタープライズデスクトップアプリケーションを設計する方法

Windows 8向けのコンシューマアプリケーション開発の期待を把握していると思います。WinRTの上に新しいMetroベースのUIを作成し、Marketplaceを介して顧客に展開すると、誰もが勝ちます。簡単そうに思えます。残念ながら、私はそのビジネスにはいません。

私は、大企業向けの内部の基幹業務アプリケーションに取り組んでいます。現在、WebまたはClickOnceを介してユーザーに簡単に展開できるリッチUIを作成するために、WPFやSilverlightなどの.NETテクノロジーを使用しています。アプリケーションは、頭痛の種なしでWinXPとWin7をサポートでき、開発者は非常に強固なUIテクノロジーであるXAMLを使用できます。

WPFとSilverlightはこの時点で疑わしい未来を持っているように思われるので、それらに投資し続けることは少し心配です。しかし、Metro UIはエンタープライズアプリケーションに適切ではないように思われ、WinRT APIはエンタープライズアプリケーションが行う必要のある「典型的な」ことに関してかなり制限されています。

現在WinXPおよびWin7にデプロイされているXAMLベースのアプリケーションをどのように設計し、Win8でサポートおよび進化できるようにする必要がありますか？

この質問の目的のために、ASP.NETの上にあるHTML5によって提供される機能は、私が作成しようとしているアプリケーションには不十分であると仮定します。一部のアプリケーションでHTML5を使用できることは理解していますが、それでは不十分な場合に何をすべきかを考えています。

編集＃1： これは、@ Emmad Kareemのコメントへの応答です。Silverlight / WPFは短期（2〜5年）で実行可能であることに同意します。ただし、私たちが作成するアプリケーションの寿命は非常に長い可能性があります（10〜20年以上）。そのため、特定のテクノロジーの長期的な存続可能性が私たちの懸念事項です。また、Silverlight / WPF開発に関心のある開発者がコミュニティによって「死んだ」と見なされると、それらの開発者を見つけることがますます困難になるという懸念があります。私は自分の選択肢を理解し、目を開けて決断をしたいだけです。

心配を止めてMS-Stackを愛することを学んだ方法

Windows 8でもVB6アプリを実行できます。MSエコシステムでは、良いか悪いかのレトロ互換性が常にトレンドとなっています。WPF / Silverightのような技術の存続について心配するべきではありません。

一方、長期的なプロジェクトでは、最新のかわいいテクノロジーは決して得られないことを受け入れなければなりません。

実際、テクノロジーの選択について自問すべき質問は次のとおりです。

• 私のチームは生産性を上げるためにそのテクノロジーに十分満足していますか？
• 私のチームはそのテクノロジーを使用して満足していますか？
• そのテクノロジーに人材を採用できますか？

それはあなたの選択を導くはずのこの質問に対する答えの組み合わせであり、主にマーケティング上の理由で作られたトレンドではありません。

この絶え間なく変化するテクノロジーのテーマの詳細については、Joel Spolsky著「Fire And Motion」をお読みください。

つまずいたのは、Microsoftの将来の方向性を把握するためにお茶の時間を読みすぎている会社です。人々は.NETを心配し、必要だと思うので、アーキテクチャ全体を.NETに書き直すことにします。マイクロソフトはあなたを攻撃していますが、彼らが前進できるように、そしてあなたが前進できないように、それはただの火です。Hailstormをサポートしますか？石鹸？RDF？顧客がそれを必要としているのか、誰かがあなたに発砲していて、あなたが応答しなければならないと感じているので、あなたはそれをサポートしていますか？大企業の営業チームは、カバーファイアを理解しています。

そして、それはほぼ10年前に書かれました。

アーキテクチャとテクノロジー

アーキテクチャとテクノロジーは、2つの別個のものであり、実行する選択肢です。

• winformsでMVCを実行できます。
• WPF / SilverlightでMVVMを実行できます。
• ASP.NETでMVCを実行できます。
• 私たちが知っている限り、MVCやMVVMなど、WINRTを使って何でもできます。
• F＃で機能することができます。何故なの ？意味のあるドメインがあります。
• それらをすべて組み合わせて、共通のシステムへのさまざまなエントリポイントを作成し、複雑になりすぎるなどの理由でm笑することができます。

サービス、リソース、サードパーティのコントロール、ORMなどをこのすべてのテクノロジで使用できます。次のテクノロジでは、場合によってはそうでない場合もあります。

これらすべてのテクノロジーを使用して、MVCをさまざまな方法でねじり曲げることができます。ビューの後ろのコードかどうか？コントローラーかどうか ViewModelを毎回、または必要なときにのみ？特定の技術の範囲内であっても、デザインパターンを実装する方法は非常に多くあります。

プロジェクトとチームの高度な知識がなくても、それらの1つに強制するのは非現実的です。それは個人的な好みにのみ基づいており、最終的には「私の技術はあなたのものより優れている」という対決になります。

正直かつ客観的に提案できる唯一のことは、適用可能なベストプラクティスを使用して、時の試練に耐えるアーキテクチャを作成することです。 。そして、そのアップグレード性/移植性は、アーキテクチャの主な目的でさえありません。

アーキテクチャと選択したテクノロジーの主な目的は、上司/顧客に現実的な要件を満たす製品を提供することです。

MVC（およびその弟のMVVM）は、1979年以来、OOP言語の分野およびそれ以降の堅牢なアーキテクチャの基盤であることがますます証明されています。しかし、10年にわたるプロジェクトでどの特定のテクノロジーを使用すべきかを選択するのは、あなたの決断のままです。

MVVMに関する私の本で説明することの1つは、パターンを活用して再利用可能なコアアプリケーションを作成する方法です。ターゲットとするさまざまなプラットフォーム（Web、Silverlight、電話、WPF、またはWinRT）のネイティブUIを作成する必要があります。ただし、ほとんどの場合、ViewModelの背後にあるUIを駆動するロジックをカプセル化できます。

アクセスするサービスは、プラットフォーム間で多かれ少なかれ移植可能なインターフェース（ファサードパターン）の背後にラップする必要があります。インターフェイスは、前面でクライアントAPIにマップし、背面でラップされたサービスのAPIに変換する必要があります。

この戦略は、新しいUIをその上に階層化するだけでよい、堅牢なコアフレームワークを作成するのに役立ちます。ビューモデルが筋肉であると考えてください。サービスはスケルトン（および臓器）を作成します。WPF / Silverlight / WinRTがスキンを形成します。

実際、私の本の非常に早い段階で指摘していることの1つは、MVVMは見た目ほど新しいものではないということです。Dolphin Smalltalkには、MMVCと呼ばれる類似のパターンがありました（2つのMはアプリケーションモデルとドメインモデルでした）。現在使用しているViewModelは、MMVCのアプリケーションモデルとコントローラーの組み合わせです。実際、多くの開発者は、ViewModelを2つのコンポーネントに分割することが理にかなっていることを発見しています（VMが他のコンポーネントを気付かないままにできるように、複数のVMのナビゲーションとオーケストレーションに使用されるコントローラー）。

XAMLは堅実であるが、WPFには疑わしい未来があると言います。何かが足りない場合を除き、WPFはXAMLを使用しているため、この2つが分離されることはありません。他のベーステクノロジーを使用している可能性のあるWPFについて、またはUIを構築する別の新しい方法を構築することをMicrosoftが検討していることについて、私が見逃しているニュースはありますか？それ以外では、WPFがどこにも行かないとは思いませんが、MSが私たちのコードのボートロードを廃止したのは初めてではありません...

リッチUIアプリが必要で、HTML5がそれを削減せず、組織がWindows OSに専念している場合、WPFは現時点で最新かつ最高であり、確かにwinformsよりも優れていると思います...

これに関する私の見解は、アプリケーションの実装の詳細にあまり焦点を合わせるべきではないということです。全体像を見ると、テクノロジーの依存関係を分離できます。たとえばxaml / wpf / silverlightへの依存をisolatinすることで、UIコンポーネント/テクノロジーを次世代テクノロジーに置き換えることができ、20年後でも継続性を保証できます。これは、システムコンポーネントを切り離し、そのような交換を実行する必要があることの影響も軽減します。（これでは、継続性を提供するために、次世代プラットフォームでそれを実現するソリューションをいじってもいいと仮定しています）

これらの技術の依存関係から分離する別の方法は、仮想化を有効にすることです。vmで実行できるような方法でアプリケーションを作成すると、20年後には実行できるようになります！