WPF 対 Silverlight: プロジェクトに最適な技術を選ぶ

原文(投稿日：2010/06/02)へのリンク

WPF を使う場合と Silverlightを使う場合について混乱がある。プロジェクトに合った技術を選ぶのは、アプリケーションの正確な要件と WPFとSilverlightの能力差に依存する。

Silverlightは、元々WPF/E (E は Everywhereからきている)で、ブラウザで走るwebアプリケーションを対象にしたWPFのサブセットである。今日では、Silverlight は、より速い開発を実現し、ずっと注目を浴び続けてきた。多くの人間は、 Silverlightを将来の Microsoftのプラットフォームだと考えている。 Mike Strobel 氏は、 Microsoftが WPF/Silverlightに関する混乱を産んだと考えている:

WPFについて改善すべき最も重要なことは、そのイメージだ、と思います。 MicrosoftはWPFをリッチデスクトップ アプリケーションのための「プラットフォーム」として押し出すべきです。そうじゃなくて、 Silverlightを「プラットフォーム」として押し出している！両方のプラットフォームを余り知らない人や Silverlightが標準の.NETライブラリと互換でないことを理解していない人たちに誤解を招く恐れがあります。

中には、WPFはやがて死ぬ、と考えている人がいるが、 Microsoft Regional Director で MVPの Brian Noyes氏は、少なくとも向こう２，３年はそのようなことは起きない、と信じている。WPFへの支持を主張するために、氏は、いくつかの点で、WPF と Silverlightで重要な差 があることを強調した:

これらは、WPFとSilverlightの基本的な能力の差であり、どちらを使うかを決める際に役立つ。開発者がなぜそちらを選んだかを説明しているいくつかの例が以下である。

Silverlightに対するWPFについての質問に答えて、Joe Gilkey 氏は、彼の会社がなぜあるプロジェクトにWPFを選び、他のプロジェクトには Silverlightを選んだかを説明した:

我々は、ソフトウェア製品を計画している時に、この疑問に直面しました。我々にとって、決定的な要因は、ローカルのハード、そして／あるいはローカルなデータベースにアクセスする必要があるかどうかでした。我々の主要製品では、１００％ローカルで走らなければなりません。我々は、情報をローカルなSQLデータベースにキャッシュする必要があり、そして、ハードウェア（GPSセンサー、シリアルポート、WCFのピアチャネル、Syncサービスなど）にアクセスできなければなりません。この製品は、WPFを使って書かれました。開発中の他の２製品は、ローカルに情報を保存しません（例外的に隔離されたストレージを使用する）ので、 Silverlightを使います。 Silverlightの両製品は、ブラウザによるインストールをサポートします。他の要素としては、WPFアプリケーションは、 Windows タッチ フレンドリに設計されています。 Surfaceチームのお陰で、WPFアプリケーションでは、 Windows タッチ用の新しい Surface Toolkitを使うことができます。

開発者のJeff氏は、なぜ彼の会社が WPFでプロジェクトを始めて後でSilverlightに変えた かを説明した:

１年前、我々は、マルチメディア配信システム用のカスタム クライアントを作るのにWPFを使いました。来年は、WPFをSilverlight アプリケーションに変えます。なぜか？現在、ほとんどのアプリケーションは、web／ブラウザベースですが、我々は、ハードウェアとやりとりでき、いくつかの他の難しい問題を解決できる静的なクライアントが必要でした。今では、Silverlight には、OOBがあり、COMを介してローカルなハードウェアに接続できます。問題は解決されました。Silverlight 対 WPFですが、顧客にとっては、インストール！です。非互換なオペレーティングシステムやスペックは、問題でありません。 Silverlightは、動くんです。そして今や、アップグレードは、簡単です、サーバのアップデートと下流のクライアントのアップデートが簡単です。そうです、WPFは、もっと強力ですが、我々には必要ありません。

WPF とSilverlightの主な違いを示して、Noyes氏が結論とするのは:

肝心なことは、もしあなたのクライアント アプリケーションが主にバックエンドデータのフロントエンドであるなら、Silverlight 4 は、完璧で充分です。しかし、もしあなたのクライアント アプリケーションが、クライアントマシンやクライアント側にある他のものと、より深い統合が必要であるなら、SL4の昇格された権限によるOOBで処理することができるかもしれません。しかしそれは、もっと手腕が要り、生産性か機能性を損なう塀にぶち当たる可能性があります。充分前もって要求分析を行う必要があります。もしクライアントマシンのリソースと重要なやりとりがあるのなら、WPFを使う方が開発が楽になるでしょう。

将来に関して、 MicrosoftのシニアPMである Pete Brown氏は、２つの技術WPF と Silverlightは、結局１つに収斂していく、と信じている:

私は最近 Microsoftで、 Ian Ellison-Taylor氏と話しました。Ianは、 MicrosoftのGeneral Manager で、 Scott Guthrieに直接報告する立場にいます。とりわけ、彼のグループは、 Silverlight と WPFの両方（そしてRIAサービスと他の多くのこと）を扱っています。将来についての内部情報が欲しいなら、彼に話すべきだと思いました。そして、彼と私は 、Silverlight と WPFの収斂について話しました。その後このことについて、メールを交換しました。

将来、 Silverlight と WPFの２つは、１つのコードベースの単一技術に、おそらくなるでしょう。結局、 Silverlightは、当初WPF/E (E は Everywhereから)として知られ、我々の通常のアプローチと驚くほど全く逆のアプローチで、醜いコードネームをつけ、それから本当に素晴らしい製品名称(Silverlight) を作り出しました。

推奨に関してはいえば、 Brown 氏の考えは、Noyes氏のに近く：「 Silverlightは、クロス－プラットフォームを対象にした最高の方法にとして、図式の右側にあり、 WPFは、左側で、 Windows 7用のマネージコード　アプリケーションを書くのに最善の方法です。」