連載：.NET中心会議議事録 第3回 Visual Studio 2010に本当に乗り換えるべきか？ デジタルアドバンテージ　一色 政彦 2010/09/02
Page1 Page2

■VS 2010で実現するユーザー・エクスペリエンス（UX）

一色　.NET開発者中心ではWPFの連載記事が人気です。その一方で、従来のWindowsフォームの連載記事も人気です。マイクロソフトは、当初、「WPFはWindowsフォームからの乗り換え先ではなく、新しいUI（ユーザー・インターフェイス）技術の1つである」という触れ込みでしたが、なし崩しに「WPFはWindowsフォームからの移行先です」というメッセージに変わってきているように感じます。変わってないでしょうか？

新村　変わってはいません。UI技術の選択肢が増えたということです。

一色　なるほど。しかしながら、「これからはWindowsフォームを捨ててWPFを活用していくべきだ」という風潮があると思います。さらにSilverlight派の人（＝UI技術の中でSilverlightを最も有力な選択肢と考える人）にとっては、「Silverlightがあれば、WPFは要らない」と主張する人もけっこうたくさんいます。いま、UIを作る技術はたくさんあり、そのせいでUI技術の選択が難しくなってきています。そこでお聞きしますが、特に業務アプリを対象として考えた場合、どのUI技術を選択すればよいのでしょうか？ まず、WPFとWindowsフォームでは、特に何が違うのでしょうか？

八巻　Windowsフォームはできることが限られています。その代わり、ある一定の範囲までであれば、プロパティ設定ベースでUIを簡単に構築できるという特長があります。

　一方のWPFは自由度が高く、かなり細かいところまでカスタマイズできるという特長があります。その代わり、Windowsフォームではプロパティ設定1つで実現できていたようなことが、WPFではXAMLコードをたくさん記述しなければならないケースもあり、そこはWPFを選択する際にハードルが高いかもしれません。

一色　それでは、八巻さんはWPFとWindowsフォームのどちらがお勧めなのでしょうか？

八巻　Windowsフォームはいま、微妙な立場にあると思います。確かに、Visual Basic 6のようにIDE（統合開発環境）でサポートされなくなったわけでもなく、.NET Framework 4＆Visual Studio 2010でも正式にサポートされています。ただし今後、マイクロソフトが大幅な機能拡張を施す予定なのは、Windowsフォームではなく、WPFの方になっています。それは.NET Framework 4にも表れています。例えばWindows 7のジャンプリスト機能などの先進的な機能はWPFにのみ標準提供し、Windowsフォームでは標準提供されていません。従って、これからUI技術を新たに選択するのであれば、WPFにすべきだと思います。しかし、開発工数などの条件や制約を考慮してWindowsフォームを選択するというのであれば、それはそれで妥当な選択だと思います。

一色　今回の.NET Framework 4では、Windowsフォームはまったく機能拡張されていないのでしょうか？

八巻　いいえ。Chartコントロールが追加されています。

一色　業務アプリに必要な機能は、WPFにも十分に搭載されているのでしょうか？

新村　業務アプリ開発ではデータグリッド（＝DataGridコントロール）は不可欠です。しかし、WPF 3.0まではリスト（＝Listコントロール）を代用するしかありませんでした。それがVS 2010のWPF 4では、データグリッドが標準搭載されるようになっており、業務アプリでのWPF利用は現実的になってきています。

一色　ところで、先ほど話題に出てきたWindows 7の先進機能は、そもそも一般的なWindows上のアプリで必要になるのでしょうか？

八巻　いまの段階では、Windows 7のそういった機能を積極的に利用したいという話はあまり聞きませんが、Windows 7以降の後続のバージョンでジャンプリストなどが標準機能になっていくことを考えると、必要とされる場面は今後増えてくると思います。

一色　川俣さんはWPFの開発については、Windowsフォームの開発と比べてどういう印象を持っていますか？

ピーデー 川俣 晶

川俣　Windowsフォーム開発に慣れている人にとっては、WPF開発へのスキル移行は難しいという感じがあります。具体的には、同じようなコントロールにもかかわらず、互換性のない部分がいろいろとあるからです。例えばWPFのListBoxコントロールには同じ内容を持つ文字列を挿入しようとすると、選択動作が期待に反する場合があるため、実際には挿入できません。これは、WPFではListBoxコントロールの項目が、文字列ではなく、オブジェクトとして管理されているからです。このような細かな違いをきちんと理解していれば問題ありませんが、Windowsフォームの開発経験があると、こういったつまらないところでつまずいて、やる気を失ってしまい、WPF開発に移行できないかもしれません。

一色　XAMLも新しく学ぶには、難しそうな感じがしますね。実際、XAMLの学習コストは高いのではないでしょうか？

八巻　XAMLは、ごく単純にいうと、XMLでオブジェクトのインスタンス生成とプロパティ設定を行っているだけなので、構文規則に慣れてしまえば、そんなに難しくはないと思います。

遠藤　でも、「添付プロパティ」などXAML特有の機能などを理解しなければならない点が難しいですよね。

川俣　確かに、例えばメニュー1つ登録するにしても「コマンドとは何か？」などと学習すべき事項が多く出てくるので、すごく簡単というわけではないと思います。

一色　Visual Studio 2010ではIDEのWPFデザイナはどう変わったのでしょうか？

新村　Visual Studio 2008では、基本的にドラッグ＆ドロップでWPFのレイアウト・デザインを作成できました。Visual Studio 2010で大きく変わった点は、データ・バインディングです。ほかにも、要素に対する色のプロパティ設定で、VS 2008までは16進数値で指定しなければならなかったのが、VS 2010では色見本の表から選択できるようになったことなど、細かい使い勝手が向上しています。

八巻　VS 2010のWPFデザイナには、細かな新機能がたくさん追加されたことで、かなり使いやすくなっていますね。特に［プロパティ］ウィンドウが、ようやくWindowsフォームのものと同じくらいに、使えるレベルになっています。例えば、プロパティの値をリセットできたりするようになっています。逆にいえば、VS 2008ではそのような当たり前のことですら、できなかったのです。

一色　Windowsフォームの場合、フォーム上にドラッグ＆ドロップでコントロールを貼り付け、［プロパティ］ウィンドウでプロパティを設定したら、そこで自動生成されたコードは基本的に開発者の目に触れず、むしろ触ってはいけないですよね。しかしWPFの場合はそうではなく、自動生成されたコードをかなり自由に編集できます。そのためかえって、WindowsフォームのようにGUIのデザイナだけを使って簡単にUIを作成できないのではないかという不安があります。

八巻　WPFデザイナのみでも、もちろんUIを作成できます。ただし、絶対配置が基本のWindowsフォームに対してWPFでは相対配置が基本となるため、そういった意味ではデザイナだけでのUI作成はWindowsフォームに比べて苦労するかもしれません。

デジタルアドバンテージ 遠藤 孝信

遠藤　Windowsフォームの場合は、フォーム・デザインがC#やVisual Basicのコードで生成されるため、（C#やVisual Basicのコードは人間向きの言語で、コンピュータによる読み取りが難しいので）編集できないという理由がありますよね。一方、WPFのXAMLコードはXML形式のため、人間が読んでも、コンピュータが読んでも、同じように解析できます。だから、人間がどんなXAMLコードを書いても、（構文が間違っていなければ）コンピュータに認識してもらえます。

一色　以前のVS 2008では、WPFのデザインを行うには、Expression Blendを使わなければならないというイメージがありました。VS 2010では、Expression Blendを使わなくてもWPFを思い通りにデザインできるのでしょうか？

新村　VS 2008でもWPFのデザインはそれなりにできていましたが、VS 2010のデザイン機能はかなり強化されています。そもそも、VS 2010のWPFデザインとExpression BlendのWPFデザインは、基本的に別物と考えていただきたい。Expression Blendを使わなければならない場面というのは、見た目をより良くしていくときです。例えばアニメーションを作りたいときには、Expression Blendを使う必要があります。

八巻　UIに対してデザインをまったく施す必要がなければ、例えば業務アプリでWPFに単純にコントロールを並べるだけの場合などは、VS 2010のWPFデザイナだけで十分です。なおVS 2008のころは、そのような単純なレイアウト・デザインであっても、XAMLコードを手書きする必要がありました。VS 2010では、複雑で高度なデザインをするのでなければ、WPFデザイナだけで何とかデザインできるというレベルにまで機能強化されています。

一色　ところで、WPFとSilverlightはどちらもXAMLをベースとしており、基本的な機能はほぼ同じです。それだったら、WPFはスキップして、Silverlightを一足飛びに採用した方がよいのではないでしょうか？ 特にSilverlightはWebベース技術なので管理性も高いので。

新村　クライアントのリソースを使いたい場合は、WPFを使いましょう。Silverlightの場合、ブラウザ外実行したとしても結局はサンドボックス（＝セキュリティ制限）の中で動作します。クライアント／サーバ型のシステム、つまりクライアント・アプリから直接、SQL Serverデータベースにアクセスするシステムを開発している場合は、WPFを使うことになります。その途中にWCFサービスを用意できるのであれば、Silverlightを使うとよいでしょう。従って、クライアントのリソースを使用するかどうかが、WPFとSilverlightの使い分け基準になります。

遠藤　WPF 4からSilverlight 4への移行は可能なのでしょうか？ 同じような機能なのだけど、微妙に違う部分がありますよね。

新村　互換性は高いですが、完全に同じではないので、単純にそのまま移行できるわけではありません。移行時に使えるコードと、使えないコードが出てくると思います。

八巻　UIの表面だけの話であれば、けっこう簡単に移行できるとは思いますが、実際にはアプリ全体のアーキテクチャも移行する必要があるので、結局、WPFアプリがWCFサービスなどを介してデータを取得するような作りになっていれば、比較的容易に移行できると思います。

一色　ここまでの話を聞いてきて、WPFも慣れればWindowsフォームと同じように開発できるという印象を持っています。現実に慣れたとして、WPFとSilverlightは、開発生産性という面でどちらが開発スピードが速いのでしょうか？

川俣　Windowsフォームでも慣れていなければ、簡単に開発できません。いろんな条件が絡むので、どちらが開発生産性が高いかは一般論としての結論は出ないと思います。

■業務アプリに活用できる新機能や新クラス

デジタルアドバンテージ 一色 政彦

一色　.NET Framework 4では並列処理に対応するクラスが追加されていますね。これは開発者にとって大きな変化になるのでしょうか？

川俣　タスク並列ライブラリ（TPL：Task Parallel Library。Parallel.Forメソッドなど）は本当に素晴らしい機能だと思います。メソッドのパラメータにラムダ式を並べて書くだけで、並列処理を実現してくれますからね。

遠藤　並列処理によりCPUコアを効率的に活用できる点は単純にうれしいですが、果たして業務アプリに必要なのでしょうか？ そもそも一般的な業務アプリでCPUの処理速度がボトル・ネックになる場面はあるのでしょうか？

新村　これは業務アプリごとに違うと思います。例えばバッチ処理などでは、複数のスレッドを立ち上げることで効率的にCPUを活用することが多かったと思います。そういった場面では、業務アプリでも並列処理は有用です。

　スレッドとの違いとして、タスク並列ライブラリでは「タスク」（task）という概念を導入しており、.NET自体が並列処理のスケジューラの仕組みを持っています。スレッドを起こす処理の場合、OS上のスレッドを立ち上げることになるので、処理実行コストが大きい。具体的には、CPU負荷は高まりますし、メモリも1セット起こすのに1Mbytesを消費したりします。そういったオーバーヘッドを低減するために、スレッドではなくタスクという概念が使われ、並列処理の高速化が図られているわけです。

　逆にいえば、非常に重い処理を複数走らせる場合では、処理全体に占めるオーバーヘッドの割合は低くなります。そのようなケースだと、オーバーヘッドを小さくしても、ほとんど高速化のメリットが得られないことになります。もちろん、スレッド処理よりも並列処理の方が、記述が簡単で分かりやすいというコーディング上のメリットは得られますが。

　また、タスク並列ライブラリの仕様として、実行順序が保証されないことに注意してください。ParallelクラスのForメソッドやForEachメソッドでは、順序どおりに実行するイメージが強いfor文を並列処理化するものであるにもかかわらず、処理できるところから処理していってしまうので、1から順番どおりには実行されません。そういった順序性を持った処理には、タスク並列ライブラリによる並列処理は向いていません。

　従って、ここまでに述べたような条件を考慮して、並列処理が適しているかどうかを判断する必要があります。

川俣　並列処理を扱うかどうかは、実はアーキテクチャの選定の際に決めるべきことです。つまり、並列処理でパフォーマンスが向上しやすいアルゴリズムやアーキテクチャを初めから選択しておく必要があります。実装済みのプログラムを並列処理にしたからといって、必ずしも高速化するわけではありません。

遠藤　単純に、Threadクラスを使っていた個所を、Taskクラスに置き換えるだけでは意味がないということでしょうか？

新村　もちろんそれで通用する場面もあると思いますが、先ほど説明したように、並列処理化する個所が軽い処理でないとスレッドからタスクに書き換えてもそれほど高速化しないかもしれません。

遠藤　ただ、将来的にマルチコアからメニー・コアの時代に移行していくことを考えると、スレッド処理をタスク処理に書き換えておけば、何年後かのそういった時代にも、そのタスクがCPUを効率的に使用してくれるというメリットもあるのではないでしょうか？

新村　将来がどのようなコンピューティング環境になっていくのかは分からないので、現時点でその将来に向けて準備するためにスレッド処理をタスク処理に書き換える必要性はないかもしれません。メニー・コア環境でタスクによる並列処理を実施しても、必ずしもスレッドよりも高速化するとは限りませんので。従って、現状でマルチスレッドで問題ないのであれば、そのままマルチスレッドにしておくことがお勧めです。

一色　ありがとうございました。

INDEX
	[連載] .NET中心会議議事録
	第3回 Visual Studio 2010に本当に乗り換えるべきか？
	1．VS 2010でのプログラミングにおける開発生産性
	2．VS 2010で実現するユーザー・エクスペリエンス（UX）

「.NET中心会議議事録」

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