Q：私たちの会社では，新しいインハウス（自社製）アプリケーションを，スマート・クライアント・モデルをベースに開発しようと考えている。アプリケーションの構築に，「Windows Presentation Foundation（WPF）」と「Windows FormsとC#の組み合わせ」のどちらを用いるべきだろうか。また仮にWPFを使うことに決めた場合，XAMLの習得にはどれくらいの時間がかかるのだろうか。C#と比較しで，どこが異なるのか教えてほしい。

　A：これは慎重に答えなければならない質問だ。3～5年後の未来であれば，この質問は恐らく無意味なものになる。そのころには，「Windows Presentation Foundation Everywhere（WPF/E）」が登場しているはずだからだ。さらに，WPF用の開発ツールも成熟し，一般的なものになっているだろう。

　しかしこの質問は，未来ではなく現在に関するものだ。筆者の回答は，「WPFとWindows Formsのどちらを使うかは，時と場合による」なのだが，これで終わらせるわけにはいかないだろう。まずWPF（とWPF/E）が何なのか，それは開発言語とどのような関係にあるのかを説明しなければならないだろう。

　WPFは宣言型のXMLを基にしており，ユーザー・インターフェース（UI）を定義するのに使われる。WPFのインターフェース記述言語には，「XAML（eXtensible Application Markup Language，zammel（ザメル）と発音する）が用いられる。理論上では，WPFがあると，同一のインターフェースをユーザーのデスクトップ上で動作させたり，Webアプリケーションの一部として提供したりできるようになる。

　WPF/Eは，WPFを「どのようなプラットフォームでも」使えるようにする追加的な機能で，デスクトップ・コンピュータやブラウザ・ベースのアプリケーションだけでなく，携帯用デバイスなども対象にできる。今年の5～6月にかけて，WPF/Eに関する情報が大量に出回っていた。だがそれ以降，情報がばったり途絶えてしまった。Microsoftは登場間近のテクノロジについて話すのが大好きだということを知っている方なら分かると思うが，この沈黙は不吉な兆候だ。

　WPFに話を戻そう。WPFの狙いは，開発者が使っているのと同じ言語で実装されたコントロールを使って作業する代わりに，WPFがコントロールを抽出し，開発者がXMLを使ってそれらのコントロールと特性を定義できるようにすることだ。サポートされていないコントロール特性を要求した場合，要求は単に無視されるだけだ。

　非常に複雑なXML構造群の場合と同様に，XAMLの構造を自力で読んだり，処理したりするのは難しい。ここで「Microsoft Expression」という開発ツールの出番となる。

WPFチームとWindows Formsチームは別

　Microsoftは2005年の「Professional Developers Conference（PDC）」から，本腰を入れてWPFの宣伝を開始し，Expressionを発表した。筆者はこのときWindows Formsチームと会う機会があった。このとき最初に驚かされたのは，WPFチームとWindows Formsチームは別だということだった。WPFはWindows Formsを基にしているわけではなく，一から作られた新しいテクノロジなのだ。会談の目的の1つは，Windows Formsにとって有益になりそうな新機能を聞き出すことだった。だが筆者が尋ねた質問は，次のようなかなり率直で，少し非礼なものだった。「WPFでもっと魅力的なインターフェースを作れるのに，なぜわざわざWindows Formsベースのアプリケーションを作る必要があるんですか？」

　この質問はWindows Formsプロダクト・チームを非常に困らせてしまったが，彼らは満足のいく答えをいくつか返してくれた。

　まず第一に，彼らが指摘したように，その時点においてExpressionツールはまだ現実のものではなかったのだ。実を言うと，Expressionがベータ版になるまでにはそれからさらに数カ月の時間が必要で，製品化には1年以上かかると，同チームは指摘したのである（PDC 2005は1年以上前の出来事であることに注意）。これは，XAMLを深く使いこなすには，テキスト・エディタのようなツールで編集作業を行う必要があることを意味していた。

　第二に，Windows Formsチームによると，「確かにWPFを使うと非常にグラフィカルなインターフェースを作れるのだが，企業環境だとこれは障害になる可能性がある」という。Windows Formsチームは続けて，「エンジニアや開発者は往々にして，本当の使い勝手と，『おい，これを使えばこんなことができるぞ！』ということの違いを見失ってしまう」と指摘している。

　さらに同チームによると，Windows FormsベースのアプリケーションをWPFベースのアプリケーションに含められるようにするインターフェース・レイヤーを開発しているそうである。私たちの会談中にはこれ以外のコメントもあったが，今回紹介した3つの点は今日でも有効である（XAML向けWebデザイナーのベータ版が，つい先日リリースされたことを思い出してほしい）。

WPFはインターフェースの定義をするだけ

　WPF/XAMLに関して最も重要な点は，WPF/XAMLはインターフェースの定義をするだけだということだ。XAMLフォーム内で，エラー処理やカスタム・ロジックを追加したりはできない。実際のところ，XAMLフォームは本物のUI Facade（ファサード，うわべ）なのだ。そのFacadeに設置するものの1つに，DLLの名前がある。DLLにはすべてのカスタム・イベント・ハンドラが存在しており，XAMLアプリケーションはカスタム応答を持つことができる。たとえ今は，WPFで自分のアプリケーションを実装しないとしても，Windows Formsベースのアプリケーション実装時に自分のアプリケーションのフォームを純粋なFacadeとして使うことによって，そのパターンを利用できるようになる。実装としては，フォーム内のコードにイベントをキャッチさせたり処理させたりするのではなく，フォームが即座にコントロールの流れをDLLにリダイレクトするのが望ましい。DLLは，実際のイベント処理のすべてを行う。もちろんこのDLLは，C++やVB，あるいはC#といった従来のプログラミング言語で記述されることになる。

　さて以上のことは，あなたにとってどういう意味を持つだろうか。まず第一に，これで1つ目の質問には答えられたと思う。あなたのアプリケーションは組織内で使用するものということなので，WPFに初めて挑戦してみるのもいいだろう。当然，管理部の許可を取り付ける必要はあるし，アプリケーション・インターフェースはシンプルなものにするのが賢明だ。幸いなことに，Windows Vistaが使用するWPFの標準のインターフェースとオブジェクトは，ここにきてかなり安定したものになっている。だから記述したコードがすぐに使い物にならなくなる可能性は，極めて低いだろう。

　もしあなたの組織の開発者が一から新しいテクノロジを学び，それを本当に理解したいと思っているのなら，WPFは価値のある投資かもしれない。だが職員が午前9時から午後5時まで働いて，与えられた職務を機械的にこなすことしか考えていない，あるいは.NETの使い方をようやく覚えたばかりなのに「別の」新しいテクノロジを学習する気などない，というような環境にいるのなら，WPFのデザインツールがもう少し成熟するまで待つのが得策かもしれない。