特集 ASP.NET vs. Struts フレームワーク徹底比較［前編］ 山田 祥寛 2004/07/28
Page1 Page2 Page3 Page4

実行環境から見るASP.NETとStruts

　さて、それでは具体的な両フレームワークの比較に入っていくことにしよう。以下は、ASP.NETとJ2EE（＋Struts）の階層構造を図示したものだ。

ASP.NETとJ2EE（＋Struts）との階層構造

この図をベースに、両環境におけるフレームワークの位置付け、開発言語、開発環境などを順に比較していく。

　この図からASP.NETとJ2EEとのいくつかの違いが明らかになってくる。

■.NET／J2EEフレームワークの位置付け

　J2EEでアプリケーション開発というと、とかく「アプリケーション・フレームワーク」の存在感は大きい。昨今のJ2EEアプリケーション構築において、「フレームワーク」なしに開発の一歩を踏み出すことは、恐らくあり得ないことだろう。

　その一方で、ASP.NETでは、フレームワークという言葉が取りざたされる機会は決して多くない。昨今ではさすがに少なくなったものの、一時期、ASP.NETに対する批判として、「フレームワークが用意されていない」などという声が聞かれたほどだ。

　このような意識の違いは、ASP.NETとStrutsとのフレームワークの位置付けの違いによるものだ。

　というのも、J2EE APIは総じてプリミティブだ。JSP＆サーブレット*の世界は、なるほどよくできている。しかし、サーブレットAPIはあくまでHTTPプロトコルの機能をそのまま置き換えたものにすぎないし、JSP APIにおいては、基本的なページ出力の機能を提供するだけだ。つまり、JSP＆サーブレット単体での生産性は決して高くない。J2EEアプリケーション開発において、ある一定の生産性を確保するには「後付けの」フレームワークを欠かすことができない。

* JSP（JavaServer Pages）は、HTML内にJavaのコードを埋め込んで実行させるための仕組み（内部的には、一度サーブレットに変換された上で実行される）。サーブレット（Servlet）は、WebサーバでJavaのコードを実行し、その実行結果をHTMLとしてクライアントに送信する仕組み。

　一方、ASP.NETでは「.NET Framework」というその名のとおり、最初から高水準のAPIとフレームワークが実装されている。つまり、ASP.NETアプリケーション開発者はフレームワークをあえて意識する必要はない。ASP.NETアプリケーションを構築するということは、すなわち、.NET Frameworkという.NETデフォルトのフレームワークを利用していることにほかならないからだ。ASP.NETアプリケーション開発者は「後付けのフレームワーク」などに頼らなくても、ただ.NET環境さえ用意すれば、即座に生産性の高い開発に取り掛かることができる。

■選択できるフレームワークと選択が不要のフレームワーク

　ただし以上の点は、半面で「選択の自由」という問題にも絡んでくる。

　というのも、J2EEの世界においては、現時点で標準的なフレームワークというものは存在しない。恐らくJ2EEの世界で最もよく知られ、普及しているフレームワークは、Apache Strutsであると思われるが、J2EEにおいてそれは唯一の選択肢ではない。

　次期J2EE 5.0では標準技術として実装が予定されているJSF（JavaServer Faces）（http://java.sun.com/j2ee/javaserverfaces/）をはじめ、ASP.NETによく似たイベント・ドリブン型のアーキテクチャを提供するJakarta Tapestry（http://jakarta.apache.org/tapestry/）、さらにはテンプレート・エンジンであるVelocity（http://jakarta.apache.org/velocity/）やO/Rマッピング・ツールTorque（http://db.apache.org/torque/）などを輩出したことでも有名なTurbine（http://jakarta.apache.org/turbine/）などを選択することも可能だ。要は、J2EEの世界では、自分自身の用途／必要性に応じて、自由なオプションを選択できる（しなければならない）。

選択できるフレームワークと選択が不要のフレームワーク

J2EEの世界では、自分自身の用途／必要性に応じて、自由なオプションを選択できる（しなければならない）。一方.NETでは.NET Framework（に含まれているASP.NET）が原則的に唯一のフレームワークだ。

　一方、.NETでは.NET Framework（に含まれているASP.NET）が原則的に唯一のフレームワークだ。もちろん、.NETアプリケーションの開発においても、サード・ベンダが提供するフレームワークを利用することはあるが、これらフレームワークも多くはあくまで.NET Framework上で動作するフレームワーク拡張であることを考えれば、.NETにおいて利用するフレームワークは.NET Frameworkに統一されているといってよい。

　ただし、この対照的な両者に対して、本稿では、.NET（あるいはJ2EE）がもう一方よりも優れていると論じるつもりはない。当然のことながら、選択の自由が与えられているということは、適切な製品（フレームワーク）を選択する責任はあなた自身に委ねられているということだ。これは、特に初学者が開発の第一歩を踏みだそうとした場合には、時として敷居を高からしめる一因ともなる。また、それぞれの技術が独立して進化を遂げているため、進化のスピードが速い半面、機能的に重複する部分をどのように使い分けていくかを、開発者自身が判断する必要がある。

　例えば、最近ではJSP（JavaServer Pages）の標準的なタグ・ライブラリとしてJSTL（JSP Standard TagLibrary）（http://java.sun.com/products/jsp/jstl/）が注目されているが、これらの機能はStrutsが提供するタグ・ライブラリと機能的に重なる部分が大きい。この場合には、より標準的なJSTLをStruts依存タグに優先して採用するのが正しいアプローチである。適切な技術が選択されているかどうかによっては、後々のバージョンアップに際して、既存のコードを大幅に修正しなければならないような事態もあり得るので、これは大変重要なポイントでもある。

　しかし、どの部分が重複しており、どの部分をJSTLで置き換えることができるのか（置き換えるべきなのか）という点については、使用している製品やバージョンの組み合わせによって変動するものであり、開発者自身が常にそれぞれの技術・製品のステータスを理解しておかないと、なかなかに把握しきれないところもあるだろう。

　一方、ASP.NETのように選択が不要であるということは、特定の製品に縛りつけられるということを意味する。いまさらいうまでもないが、ASP.NETは原則としてWindows＋IIS（Internet Information Services）でしか動作しない。去る2004年6月に、LinuxなどのUNIX系OS環境で動作するオープンソース版 .NET環境であるMono 1.0（http://www.mono-project.com/）が正式リリースこそされているものの、そのユーザー数もさほどには多くない中で、現実的にはまだUNIX環境での.NET開発が一般的になるのは先の話だと予想される。

　つまり、ASP.NETを採用するということは、（少なくとも現時点では）マイクロソフトに依存するということとほとんど同義である。しかし、その半面で、製品選択や製品間の相性といったアプリケーション開発とは本来関係ないはずの問題にとらわれることなく、アプリケーション自体の設計・コーディングに専心することができるということでもある。

　「自分自身で責任を負うべき自由」を選択するか、「限られた環境下での楽園」を選択するかは、開発者やマネージャである読者諸兄が決めるべきものだ。

　続いては、開発言語やツールといった開発環境の観点から、2つのフレームワークを比較する。

INDEX
	［特集］ASP.NET vs. Struts フレームワーク徹底比較［前編］
	1．フレームワークとは何か？
	2．実行環境から見るASP.NETとStruts
	3．開発環境から見るASP.NETとStruts
	4．フレームワークの内部構成
	［特集］ASP.NET vs. Struts フレームワーク徹底比較［後編］
	1．ユーザー・インターフェイス構築要素
	2．入力妥当性チェック機能／アプリケーションの構成ファイル
	3．セキュリティ管理／セッション管理／国際化機能
	4．キャッシング機能／テンプレート機能

　

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