第1回　ASP.NETがもたらす次世代のWebプログラミング：連載 プログラミングASP.NET　―ASP.NETによるWebアプリケーション実践開発講座―　（1/4 ページ）

連載目次

　日本語版Visual Studio .NETの発売がいよいよ開始され、「MS-DOSからWindowsへの移行に匹敵する革新」といわれる.NETプラットフォームがいよいよ本格的に立ち上がろうとしている。.NETは極めて多彩なテクノロジの集合体だが、中でも.NETプラットフォームのけん引役と目されているテクノロジがASP.NETである。

クライアントとサーバの垣根を取り払う.NET

　.NETとは何か。これほど大規模なプロジェクトともなるととらえ方によって見え方もさまざまだが、1ついえるのは「クライアント・サイドとサーバ・サイドの共通プラットフォーム」であるということだ。デスクトップ・アプリケーションと、サーバ・サイド・アプリケーション（Webアプリケーション）を同一のプログラミング言語とAPI（.NET Framework）で開発できるシステムだ。

　従来、デスクトップ・アプリケーションとサーバ・サイド・アプリケーションは、まったく異なる基盤の上に構築されていた。異なる言語、異なるAPI、異なるライブラリ。いずれも一致するところはなく、同一のOS上で動作してはいても、まったく別のプラットフォーム上で動作しているに等しかった。しかも、サーバ・サイド・アプリケーションの開発には、HTML、CSS（Cascading Style Sheets）、HTTPといったデスクトップ・アプリケーションの開発には無縁だったWebテクノロジの知識が必須であり、C／C++言語やVisual Basicのユーザーにとっては敷居の高いシステムといえるだろう。Javaはデスクトップとサーバ・サイドの両面で活躍できる数少ない言語の１つだが、デスクトップでの実用性には疑問が残る。現時点では、やはり適材適所に言語やプラットフォームを使い分けるのが現実的な選択だ。

　しかし.NETでは、プラットフォームの共通化によって、共通の知識に基づいて、デスクトップ・アプリケーションとWebアプリケーションの双方を開発可能となっている（下図）。それでは、.NETではどこが共通化されているのだろうか。

クライアント・サイドとサーバ・サイドの共通プラットフォーム
言語の等価性、ライブラリの共通化、イベント・モデルの採用などによって、.NET上ではターゲット・アプリケーションによらず、共通の知識で開発が可能。

−共通化のポイント その１−あらゆる言語がクライアント・サイドとサーバ・サイドで利用可能

　.NETの解説では必ず触れられているので、すでにご存じの読者も多いだろうが、.NETのランタイムである共通言語ランタイム（CLR：Common Language Runtime）上では、すべての言語は等価に扱われる。完全に等価というわけではなく、言語によってできること、できないことはあるにせよ、基本的にある言語で記述したプログラムは、ほかの.NET言語で書き直すことが可能だ。こうした言語の等価性に加えて、.NET言語はいずれもデスクトップ・アプリケーションとサーバ・サイド・アプリケーションの開発に利用できる。具体的にいえば、C＃、Visual Basic.NET（以下VB.NET）、JScript.NETのどれを使っても、両サイドのアプリケーション開発が可能だ（C++.NETはポジションが特殊なので除外。サーバ・サイドの埋め込みコードには利用できないなど制限がある）。

　いままで「仕方なく」JScriptやVBScriptでASPページをデザインしていたサーバ・サイド・プログラマー諸氏は、C#やVB.NETのようにパワフルな言語を長い間待ち望んでいたことだろう。いまどきオブジェクト指向が取り入れられていない、データ型のあいまいな言語で本格的なアプリケーション開発を行うのは、できれば遠慮したいものだ。

　またJScript.NETは.NET言語でありながら、相変わらず変数をバリアント型（値を代入したときに型が決定する変数型）のように曖昧なデータ型として扱う手軽さを損ねてはおらず、この手軽さをそのままに、DirectXを使ったゲームや、Windows 2000／XPで動くサービスの開発に利用できる。もはやC言語やJavaの面影を残した非力な言語というイメージはない。

　.NETの世界では、もはや用途に応じた言語の使い分けは必要ないのである。

−共通化のポイント その２−ターゲット・アプリケーションに依存しない.NET Framework

　.NETの言語が等価的であるのはCLRによるところが大きいが、クラス・ライブラリが共通化されているのも大きな理由の1つである。開発対象がクライアント・サイドかサーバ・サイドかにかかわらず、.NET Frameworkとして体系的に設計されたクラス・ライブラリを共通に利用できるのだ。

　例えば、株価グラフを表示するウィンドウ・アプリケーションを開発するとしよう。このとき画面表示に使うクラスがGraphicsクラス（図形描画用クラス）とBitmapクラス（ビットマップ処理および仮想画面用クラス）だ。あなたがWin32プログラマーならば、それぞれデバイス・コンテキストとビットマップ・オブジェクトに相当するといえば、イメージがわきやすいだろう。GraphicsクラスのDrawLineメソッドやDrawStringメソッドを使ってグラフを描けば、それがウィンドウに表示される。

　それでは次に、Webアプリケーションでも同じように株価グラフを表示したいとしよう。このとき使うクラスも、やはりGraphicsクラスとBitmapクラスなのだ。まったく同じクラスとまったく同じメソッドを使って、グラフを描くことができる。Webアプリケーションでは、その後結果をGIFやJPEG形式でファイルに保存し、これを<img>タグのソースとして指定するという独特の作業があるにせよ、大部分のコードは共通化されることが想像できるだろう。

　表示処理を例に取り上げたが、共通化されるコードはこれだけではない。それどころか、ファイルの入出力、データ・アクセス、ネットワーク通信、XML操作など、.NET Frameworkで定義される大部分のクラスは、デスクトップ・アプリケーションとWebアプリケーションの双方で共通して利用可能だ。

　オブジェクト指向プログラミングが浸透するにつれ、ライブラリはより多機能に、より便利になってきたが、同時に大規模化が進み、プログラマーの負担は増える一方だ。いまや新しいジャンルへの挑戦における最大の難関は言語の習得ではなく、ライブラリの習得にあるのは間違いない。そして、この傾向は今後さらに加速していくだろう。その点、.NETではターゲット・アプリケーションや言語によらず、たった１つのクラス・ライブラリを習得するだけで済むので、いずれも同じような機能を持っている別々のライブラリを言語ごとに習得するような無駄は必要ない。新しいライブラリがリリースされたとき、即座にあらゆる環境で利用できるようになるのも、共通化がもたらすメリットの１つである。