Windows 8以降のマイクロソフトのアプリケーション開発技術
Windows 8が登場すると、Metroスタイルという新しいアプリケーションの形態が追加されるため、アプリケーションの開発技術の選択肢はさらに増えることになります。しかしながら、Windowsプラットフォーム上で実行される多くの業務アプリケーションにとっては、WPFかSilverlightのどちらかになる（もちろんWindowsフォームも実行可能）という状況はそれほど変わっていないと思います。
もし、どのアプリケーション開発技術を選択してよいかわからないという場合には、下記のblogに書かれたフローチャートが役に立つかもしれません。
ここからは私個人の意見です。あくまでも個人の意見ですので、書き手の都合の良いように解釈、判断している部分もあるかもしれません。
WPFかSilverlightのどちらかを選択するということは変わっていませんが、今後はSilverlightよりもWPFを選択するケースがこれまでよりも多くなるのではないかと予想します。その理由は以下のようなものです。
Silverlightの居場所は？
これまでは、Silverlightがマイクロソフトのアプリケーション開発技術の中で最もマルチに対応できる選択肢だったと思います。それはWindowsアプリケーションからWebアプリケーション、ビジネス向けのアプリケーションからコンシューマ向けのアプリケーションまでといった具合にです。しかしながら、現在の状況、そして今後の流れを考えた場合、その状況は変わってくると予想します。
WindowsアプリケーションとWebアプリケーション（クロスプラットフォーム）
かつてSilverlightはその特徴の一つとして「クロスプットフォーム」を大きく掲げていました。しかしながら、Silverlightは徐々にクロスプラットフォームをあきらめていったように思います。
フルサイズのWebブラウジングがPCだけのものだった時代には、PCの主要なプラットフォームさえカバーできればクロスプラットフォームであると言えました。つまり、今現在のSilverlightがサポートするWindowsとMacの2つだけでも十分だったのです。しかし、スマートフォンやタブレットといったPC以外のWebブラウジング環境は、すごい勢いで増え続けています。かつてWindows MobileやNokiaをサポートするとアナウンスされていたSilverlight 2 for Mobileはキャンセルされました。そして、Windows Phone上に載っているSilverlightは通常のアプリケーションプラットフォームであり、Webブラウザーのプラグインではありません。
Silverlight 4では、Mac環境をサポートしない「COMオートメーション」が追加されました。このことは、Silverlightのクロスプラットフォームに対する方向性の転換を示すものととらえることもできます。今年中にリリースが予定されているSilverlight 5でも、Windowsプラットフォームのみの機能である「P/Invoke」が追加される予定です。
そして、マイクロソフトが本当の意味でのクロスプラットフォームはHTML5だと考えていることは、下記のボブ・マグリア氏発言、そしてMetroスタイル版のInternet Explorer 10がプラグインをサポートしないことからも明らかではないかと思います。
マイクロソフトが戦略変更。HTML5が唯一のクロスプラットフォーム、SilverlightはWindows Phone 7のプラットフォームに － Publickey
Windows 8のタッチUI用IE10はプラグインに非対応。FlashもSilverlightも使えず － Publickey
これらのことから、私はSilverlightの活躍場所はクロスプラットフォーム（Webアプリケーション）ではなく、Windowsアプリケーションであると考えています。
コンシューマ向けアプリケーションと業務アプリケーション
SilverlightがWPFに対して持っているアドバンテージとして、DeepZoomやSmooth Streamingといった機能があります。これらは業務アプリケーションよりも、コンシューマ向けのアプリケーションで使われる機能です。
これまではWindowsアプリケーションの開発技術に、業務向けもコンシューマ向けも区別はありませんでした。しかしながら、Windows 8がリリースされると多くのコンシューマ向けアプリケーションがMetroスタイルとして作成されることになると思います。また、多くの場合、SilverlightはWPFに比べMetroスタイルアプリケーションへの移行が簡単です。そのため、新規のアプリケーションだけでなく既存のコンシューマ向けSilverlightアプリケーションもMetroスタイルアプリケーションとして登場することが予想できます。これは、今後MetroスタイルアプリケーションでDeepZoomやSmooth Streamingが提供されるかどうかも大きく影響するでしょう。
これらのことから、私はSilverlightの居場所は徐々に業務向けに偏ってくるのではないかと考えています。
Silverlightの居場所
Silverlightの主な活躍場所は業務向けのWindowsアプリケーションです。これまでと異なり、ほぼ同じ土俵でSilverlightはWPFと比較検討されることになるのではないでしょうか。
WPFのアドバンテージ
業務向けのWindowsアプリケーションという土俵で両者を比較した場合、WPFはSilverlightに比べて以下の点でアドバンテージがあると思います。
Windowsフォームからの移行
業務アプリケーションの開発において純粋な意味での新規開発は少なくなってきており、WPFかSilverlightかを選択する機会というのは主に既存のアプリケーションの移行になるのではないかと思います。現在、Windowsプラットフォーム上の業務アプリケーションで最も多いのは、Windowsフォームではないかと思います（その次はもしかしたらVisual Basic 6.0かもしれません）。したがって、Windowsフォームから移行がしやすいかどうかは、WPFかSilverlightかを選択するうえで重要なポイントになるのではないかと思います。
WPFは、Silverlightに比べて以下のような点でWindowsフォームに近いと言えます。
- サブセットではないフルの.NET Frameworkクラスライブラリを使用できる
- サービスを経由することなく直接ADO.NETを使ってデータベースにアクセスできる
また、Windowsフォームから段階的な移行がしやすいのもWPFの特徴です。WPFではWindowsFromsHostコントロールを使ってWPF要素内にWindowsフォームコントロールを表示することができます。先の投稿で紹介したように、WPF4.5において「WPFでホストされているWindowsフォームコントロールが常にWPFコンテンツの一番上に表示される」という問題が改善されるため、WindowsFromsHostを使って一部分をWindowsフォームのままとするWPFアプリケーションがより現実的なものとなります。
開発生産性
Silverlightは、ランタイムのサイズをコンパクトに保つため、同じ名前のクラスやメソッドでもWPFに比べてメンバ数が少なかったりオーバーロードの数が少なかったりします。特に、「結果的には同じことができるがこれがあると便利」といった類のものの多くは実装されていません。
たとえば、WPFのColor構造体には新しいColor構造体を作成するためのメソッドが5つ存在しますが、Silverlightは1つだけです。
| メソッド名 | WPF | Silverlight |
|---|---|---|
| FromArgb | ✓ | ✓ |
| FromAValues | ✓ | - |
| FromRgb | ✓ | - |
| FromScRgb | ✓ | - |
| FromValues | ✓ | - |
このような差は機能レベルで比較された場合には違いとして出てきませんが、開発生産性に影響する可能性があります。
タッチ操作への対応
Windows 8により、タッチ可能なWindowsというものが世の中に普及することになります。タッチ可能なデバイスではMetroスタイルのアプリケーションを使用するのがベストだと思いますが、業務アプリケーションにおいては既存資産やコストの兼ね合いから、既存のアプリケーションを最低限のタッチ操作に対応させたいといった需要も少なからず生まれてくると予想します。
また、タッチ可能なデバイスはスレート／タブレットPCだけとは限らないと思っています。タッチディスプレイの生産コストが下がれば、需要があるなし関係なくタッチ可能なデスクトップPCというのも徐々に増えてくると予想します。PCメーカーとしても、Windows 8を搭載しているにも関わらずタッチ機能が備わっていないPCは売りづらくなるでしょう。これにより、デスクトップで基本的にはキーボードとマウスを使いながらも、一時的、あるいは部分的にタッチを使って操作するという人もちらほらでてくるのかもしれません。
タッチ操作への対応において、WPFは以下の2点でSilverlightよりも有利です。
これまでSilverlightが有利だったもの
これまで業務向けのWindowsアプリケーションにおいてWPFよりもSilverlightが有利とされてきた点のいくつかは、今後改善されていくと思います。
ランタイム環境のセットアップ
下記の記事で書いた通り、SilverlightはWPFに比べてランタイム環境のセットアップが容易です。
これは主にランタイムのインストーラーサイズが5MB台と小さいためであり、いくら.NET Framework 4で大幅にインストーラーサイズが削減されたといっても、有利であることに変わりはありません。しかしながら、プリンストールされているOSがあるという点では、.NET Frameworkが有利であると言えます。そして、現在一般的に使用されているWindows OSの中で唯一.NET FrameworkがプリインストールされていないWindows XPは、もはや一番多く使用されているWindowsではなくなりました。
アプリケーションの起動速度
WPFではなくSilverlightを選択した理由として、WPFアプリケーションの起動の遅さをあげているケースがありました。.NET 4.5ではCLRに以下の5つの改善が施されており、それらは主にパフォーマンスに関するものとなっています。
- Background mode for Server GC
- Managed Profile Guided Optimization
- Automatic NGEN
- Multi-core background JIT
- Re-JIT
紹介のされ方を見るとMetroスタイルアプリケーションのためという要素が強いようですが、これらはWPFなどのMetroスタイルではない.NETアプリケーションにとっても有効な改善です。特にこれまでネイティブコードでしか利用できなかった「PGO (Profile-Guided Optimization) 」がCLRで実行されるアプリケーションでも利用可能になるというのは、非常にインパクトが大きいと感じます。
最後に
このほかに影響しそうなものとして、WCF RIA ServicesとVisual Studio Light Switchをあげておきます。これらは特に今回動きがありませんが、今後注目しておきたいポイントです。
