特集：XAMLファミリ共通開発のすゝめ（前編） Windows 8時代のGUI開発を考える 岩永 信之 2011/12/02
Page1 Page2 Page3

■一貫性のある開発スタイル

　これまでの説明どおり、XAMLファミリ間で、100％のコード共有はできないが、いずれの開発スタイルも非常に似ている。1つ覚えれば、ほかのフレームワークに移ることは簡単だろう。

　このXAMLファミリ内で一貫した共通の開発スタイルについて説明しておこう。

◆XAML＋.NET Framework言語

　本稿でWPFなどの総称を“XAMLファミリ”と呼ぶことにした由来でもあるが、いずれのGUIフレームワークも共通して、XAMLでビューを記述する。

　まず、Figure 5を見てもらおう。これは、Visual StudioでのXAMLファミリの開発の様子だ。この例では、1つのソリューションに3つのGUIプロジェクトと、1つの共通ライブラリ・プロジェクトが含まれている。

Figure 5: XAML＋.NET言語によるGUIアプリの開発例

　上段は、横に3つ並べて、それぞれWP7、Silverlight、WPFのデザイン画面とそのXAMLコードである。対して、下段左側がC#コード（共通ライブラリ中で定義）、右側がソリューションの構成となっている。

　XAMLファミリすべてに共通して、視覚的なデザインをXAMLで、残りの部分を.NET Frameworkに対応した言語（C#やVBなど。以下、「.NET言語」と表現）で記述する。

　Figure 5の上段を見てのとおり、簡単なものならほとんど同じXAMLコードで書ける（ただし、前述のとおり、操作性の観点からいうと、書き換える方が適切な場面も多いだろう）。

◆Visual StudioとExpression Blend

　すでに前節のFigure 5に示してしまったが、XAMLファミリはいずれもVisual Studioを使って、同じ操作性でGUI開発できる。

　また、開発者よりはUIデザイナー向けのツールであるExpression Blend上でも、共通の操作が可能である。

　ここで、詳細は後述することになるが、Portable Class Libraryについても軽く触れておこう。Figure 5だけでは見づらいと思うので、ソリューションの部分を抜き出したものをFigure 6に示す。

Figure 6: Figure 5のソリューション構成

　1つのライブラリ（Portable Class Library）を、3種類のGUIプロジェクトから参照している。

　このように、異なる種類のGUIプロジェクトで、ライブラリを共有できるようにするのがPortable Class Libraryである。次節で説明するデータ・バインディングを駆使すれば、アプリの大部分をこのPortable Class Libraryとして作った共有ライブラリ・プロジェクトに置けるはずだ。

◆データ・バインディング

　プラットフォームに依存しやすいUI層から、処理の大部分を共通ライブラリ化するためには、いわゆるビュー（view: 表示部分を担うクラス）とモデル（model: 計算や、データ検証、データベースなどに対するデータ読み書きを担うクラス）の分離が必要である。

　XAMLファミリにおいて、ビューとモデルを分離するため機構として、Figure 7に示すような、データ・バインディングというものを提供している。

Figure 7: XAMLコード＋.NETコードでのGUI開発

　図中のコードは要点だけ残して一部を省略している。例としてC#を使っているが、.NET言語であれば何でも利用可能である*5。

*5　ただし、XAMLからのコード生成をしている部分がC#とVBにしか対応していないため、XAMLコードと同一のプロジェクト内に置きたいコードはC#かVBの利用が必須。

　ビュー側はXAMLコード中のどこにどのデータを表示するかという印だけを残し（極力XAMLコードだけでビューを記述し）、データ（＝モデル、もしくは、それをデータ・バインディング向けにラッピングしたもの）を外部から与える。

　データの変化に応じた再描画処理や、データ・コレクションからリストなどを生成する処理を、.NET言語コードで書かない（＝データ・バインディング機構に任せる）のがポイントだ。

■XAMLファミリ間の差

　XAMLファミリ間での差を考えるうえで、以下のような視点を分けて考えてほしい。

• .NET Framework
• 実行環境自体
• プロファイル（＝利用可能なクラス・ライブラリの範囲）
• XAML
• XAMLの解釈の仕方
• 利用可能なXAMLタグ（＝プロファイルによって決まる）

　先に結論だけいってしまうと、XAMLファミリ間の差は、ほぼプロファイルの差といえる。

◆.NET Frameworkの差

　.NET Frameworkに関しては、Figure 8に示すように、実行環境とプロファイルに分けて考えよう。

Figure 8: XAMLファミリの実行環境とライブラリ

●実行環境の差

　.NET Frameworkのうち、実行環境の部分に関しては、各フレームワークの差は性能的な細かい差のみである。性能要件が厳しい場合や、性能差に依存するような（あまりよくない）コードを書かない限り、どのフレームワークでも同じ挙動と考えて差し支えない。

　ここでいう「実行環境」には、以下のようなものを含む。

• 型システム
• ガベージ・コレクタ（GC）
• JIT（Just-In-Time）コンパイラ
• スレッド・プール

　それぞれの差をTable 4に示す。

フレームワーク	説明
WPFとMetro	いわゆる通常のCLRである。WPFとMetroは同じものを使っている
Silverlight	通称で「CoreCLR」と呼ばれる実行環境を使っている。CLRとの差は小さい。例えば、起動時間の短縮を優先し、JITコンパイルの最適化を少なめにしているなどという差である
WP7	WP7の実行環境は、.NET Compact Frameworkのものがベースとなっている。携帯機器などの低スペック環境向けに最適化されているため、CLRとはGCやJITコンパイルの性能が異なる
Table 4: XAMLファミリの実行環境の差

●プロファイルの差

　SilverlightやWP7でも、実行環境自体には大きな差がなく、差に悩まされるとすると、ライブラリの差の方である。

　ビューに関するクラス（＝XAML中にタグとして書けるもの。コントロールなど）は次節に譲るとして、ここでは、モデルで使うようなクラスについて説明する。

○WPF

　もともと、.NET Frameworkには参照可能なライブラリの種類を規定する「プロファイル」というものが2種類ある。

• Full: もともと、単に「.NET Framework」と呼ばれていたもの。すべてのライブラリを参照できる
• Client Profile: クライアントPCへのインストール時間短縮のため、サーバ側でしか使わないような機能を削除したもの*6

*6　確かに、クライアント・アプリケーションを作るうえで困ることは少ないが、全くないわけではない。例えば、HttpUtilityクラス（System.Web名前空間）がないため、URLエンコード／デコードができないなどがよく不満に挙がる（.NET Framework 4以降ではSystem.Net名前空間のWebUtilityクラスが利用可）。

　Silverlight、WP7、Metroなどが加わるというのは、このプロファイルの種類が増えるようなものだと思ってほしい。

○Silverlight

　Silverlightは、クライアントPCへのインストールの負担を軽減するという目標があり、インストール・サイズ縮小のため、ライブラリがかなり削られている。

　Client Profileと同様にサーバ側でしか使わないような機能が一切ないことに加えて、以下のようなものが削除されている。

• セキュリティ的にブラウザ内実行で使えないもの
• 互換性のためだけに残されているような古いクラスやメソッド
• ほかのメソッドで代用可能なもの
• オーバーロードも、最も汎用性の高い1つを残して削られているものがある
• ネットワーク・アクセスなどの同期呼び出し版
• すなわち、非同期呼び出しを強制される

　基本的には、なくても困らないものや、使えるとまずい機能、使ってほしくない機能の削除である。

○WP7

　Windows Phone OS 7.0の場合はおおむねSilverlight 3相当、7.1（製品名としては「Windows Phone 7.5」と呼ばれているもののOSバージョン）の場合はSilverlight 4相当のライブラリが利用できる。

○Metro

　Windows 8への依存度の高い部分は、System名前空間から外れ、「WinRT」というネイティブ実装の別ライブラリに分離された（WinRTについては後ほどあらためて説明する）。そして、最小限の機能だけが.NETのライブラリとして残されている（アセンブリの置かれているパスの名称から「.NET Core」という通称で呼ばれている）。

　.NET Coreから削除されているのは以下のようなものである。

• GUIに関する部分 → WinRT側へ移動
• ファイル・アクセスなどの権限を要する機能 → WinRT側へ移動
• 古いもの、重複のあるもの → Silverlightと同様に削除

○Portable Class Library

　モデルで使うようなクラスに関しては、どの種類のXAMLファミリでもほぼ共通している。WPFにしかないクラスやメソッドは、ここまでの説明の繰り返しになってしまうが、以下のようなものだけである。

• なくても困らないもの
• 互換性のためだけに残されている古いクラス
• ほかのオーバーロードで代用可能なメソッド
• 利用が推奨されないもの
• ネットワークの同期呼び出しなど
• セキュリティ的に、強い権限がないと実行できないもの
• データベース・アクセス系
• Webサービス経由でのアクセスを推奨

　残りの部分に関しては、すべてのXAMLファミリで共通利用可能である。

　そこで登場したのが「Portable Class Library」だ。名前のとおり、すべてのXAMLファミリから参照可能なポータブルなライブラリである（もちろん、Figure 9に示すように、共通するクラスだけを利用できる）。

Figure 9: Portable Class Library

　Portable Class Libraryを利用するためには、Visual Studio 2010では、以下の拡張機能をインストールする必要がある。

• Portable Library Tools

　一方、次期バージョンのVisual Studio（現在、プレビュー版は、内部バージョンに基づき「Visual Studio 11」と呼ばれている）では、標準でPortable Class Libraryを利用できる。

◆XAML

　XAMLにもいくつかの側面がある。分けて見ていこう。

・オブジェクト記録形式としてのXAML

XAMLは、XMLで.NETオブジェクトを記録するための形式の一種である。XAMLのタグと、.NETのクラスは1対1に対応している。 この仕組みは、XAMLファミリのGUIフレームワークだけでなく、Windows Workflow Foundationなど、ほかのフレームワークでも使われている。 どのフレームワークにおいても、この挙動は変わらない。

・コード生成の仕組みとしてのXAML

XAMLファミリでは、定型文的なコード（左記の例ではAppクラスとMainメソッド）を、XAMLファイルから自動生成している。 この方式はどのXAMLファミリでも共通である。生成されるコードに多少の差はあるが、挙動まで変わることはない。

・XAMLスキーマ

前述のとおり、XAMLコード中に書くタグは、.NETのクラスと1対1に対応している。 従って、XAMLのスキーマ（＝どのタグが使えるか）は、.NETのプロファイル（＝どのクラスが使えるか）に対応する。 これは、XAMLファミリ間で差がある。

　やはり、仕組み的な部分には差がなく、プロファイルの差（＝スキーマの差）だけとなる。

　ビュー関連のプロファイルの差に関しては本稿では割愛する。詳細はMSDNライブラリなどを参照していただきたい。有志の方がまとめてくれている場合もある。例えば最近のものでは、以下のようなブログ記事がある。

• 4つのテクノロジーのControls名前空間を比較（グレープシティ八巻氏によるブログ）

　また、足りてないものの中には、Toolkitっという形で別途提供されているものもある。

• Silverlight Toolkit

　ちなみに、プロファイルの差は、XAMLタグとして使える要素の差だけでなく、データ・バインディングの挙動の差などにも表れるので、細かく見ると注意が必要である。

　次のページでは、WinRTについてもう少し詳しく説明する。

INDEX
	特集：XAMLファミリ共通開発のすゝめ（前編）
	WINDOWS 8時代のGUI開発を考える
	1．“XAMLファミリ”／GUIフレームワークの分岐
	2．一貫性のある開発スタイル／XAMLファミリ間の差
	3．WinRT
	特集：XAMLファミリ共通開発のすゝめ（後編）
	MVVMパターンを使ったクロス・ターゲット開発
	1．ソース・コード共有の方法／サンプル・アプリ
	2．Portableプロジェクト／リンク・プロジェクト／個別プロジェクト

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）