特集 ASP.NET vs. Struts フレームワーク徹底比較［後編］ ―― Webアプリケーション構築のための2大基盤を比較する ―― 山田 祥寛 2004/08/25

Page1 Page2 Page3 Page4

　前編では、ASP.NETとStrutsという代表的な2つのアプリケーション・フレームワークをマクロ的な視点で比較した。後編となる今回は、これらフレームワークのより詳細な個別機能について、つまびらかに見ていくことにしよう。

　具体的には、アプリケーション・フレームワークを選択する際、あるいはWebアプリケーションを構築する際に考慮しなければならない以下のポイントについて見ていく。

・ ユーザー・インターフェイス構築要素	・ セッション管理
・ 入力妥当性チェック機能	・ 国際化機能
・ アプリケーションの構成ファイル	・ キャッシング機能
・ セキュリティ管理	・ テンプレート機能

　本稿では、ページ数の都合上、各機能の詳細にまでは踏み込まないが、できるだけ参考資料を明示するよう努めているので、興味（必要）に応じて、併せて参照することで理解を深めていただきたい。

ユーザー・インターフェイス構築要素

　ASP.NETとStruts（J2EE）は、ともにユーザー・インターフェイス（MVCモデルにおけるビュー。MVCモデルについては前編の「フレームワークの内部構成」を参照）の開発を効率化する目的で、タグの形式で動的な処理を実現できる仕組みを提供している。

　この仕組みを、ASP.NETの世界では「サーバ・コントロール」、Struts（J2EE）の世界では「アクション・タグ」と呼んでおり、それぞれに多くのコントロール（タグ）を提供している。だが、その具体的な内容を比較してみるとどうだろう。

■サーバ・コントロールとアクション・タグ

　例えば、データベースから取り出した結果セット（データセット）を一覧表に整形する場合、ASP.NETではDataGridコントロールやDataListコントロールなどのサーバ・コントロールを利用すれば、ページ本体を記述している「.aspx」ファイルには、ほとんどプログラム・コードを記述する必要はない（参考「DataGridコントロールでデータセットを表示するには？」ほか）。

　また、DataGrid／DataListコントロールには、更新／削除／ソート／ページングなどの典型的な機能があらかじめ実装されており、リスト・データの表示や編集という、ビュー開発において最も煩雑になりやすい機能の大部分をプログラム・レスで実現している。

　一方で、Strutsで同様のことを実現するには、<c:forEach>タグ（または<logic:iterate>タグ）のような繰り返し処理のための汎用的なタグを利用して、1から表組みを整形する必要がある（参考「Strutsとデータベースの連携を学ぶ」）。もちろん、データ編集やソート、ページングなどの処理を実装するには、あらためて自前の仕組みを用意する必要があるだろう。

　以上はごく一例にすぎないが、ASP.NETには、このほかにもCalendarコントロールやAd Rotatorコントロールなど、複合的な機能を持ち合わせたコントロールが多数用意されている（参考「Visual Studio .NETでプログラム・レス開発を学ぶ（中編）、（後編）」）。

　また、2005年に登場予定のASP.NET次期バージョン「ASP.NET 2.0」では、サイト・メニューを動的に作成するMenu、TreeView、SitePathコントロールや、ログイン機能を構築するためのLogin、CreateUserWizard、PasswordRecoveryなどのセキュリティ・コントロール、ウィザード形式のページ・セットを作成するためのWizardコントロールなどなど、より高機能なコントロールが追加される予定だ。ASP.NETのサーバ・コントロールは、今後より一層、多機能な機能――ものによっては、むしろページ・テンプレートに近い機能――を提供するようになっていく傾向にある。

　対するStrutsタグ・ライブラリ（あるいはJSTL：JSP Standard TagLibrary）は、既存の制御構造（またはHTMLタグなど）を1対1の関係で置き換えただけの、ごく原始的な機能を提供するにとどまる（Strutsが提供する主なタグ・ライブラリについては、拙稿「フレームワーク・プログラミングの準備」を参照）。

　そして、この傾向が今後劇的に変化することは（恐らく）ないだろう。というのも、Strutsの主たるフォーカスは、今後とも変わらずコントローラ部分にあるからだ。特定の目的に特化したビュー部品によって、フレームワーク自体が不必要に多機能になることを、Strutsは好まない。その点で、ビューにフォーカスするASP.NETと、Strutsの目標としているところはおのずと異なることがお分かりになるだろう。

　もしもStrutsでユーザー・インターフェイス（ビュー）の開発を効率化したい場合には、Strutsをベースとした拡張フレームワークの採用を検討する必要がある（参考「システム開発最前線〜サーバーサイド技術におけるフレームワーク比較〜」のP.16）。あるいは、さらに将来的な視点を含めれば、今後、普及が進むと思われるJSF（JavaServer Faces）とStrutsとの組み合わせという選択肢も視野に入ってくるかもしれない。

■「ブラウザ検出」機能

　もう1つ、ASP.NETのサーバ・コントロールの特徴的なポイントとして「ブラウザ検出」機能が挙げられる。

　サーバ・コントロール（正確には「Webサーバ・コントロール」）は、クライアントであるブラウザが「HTML 4.0」「JScript 1.2」「MSDOM（Microsoft Document Object Model）」「CSS（Cascading Style Sheet）」といった仕様に対応しているかどうかによって、クライアントを「上位ブラウザ」「下位ブラウザ」に分類する。そして、上位ブラウザに分類されたクライアントに対しては、ダイナミックHTMLやCSSをフルに活用したページを出力するが、下位ブラウザに対しては純粋なHTML 3.2準拠のページを生成し、動的な操作はすべてサーバ・サイドに委ねることができる。ASP.NETでは、これによって、サーバ／クライアント間の役割分担をクライアント環境に応じて、適切に配分しているというわけだ。しかし、Strutsタグ・ライブラリには、こうした検出機能は実装されない。

　もっとも、「ブラウザ検出」機能については、今後、JSFで本格的に実装されていくものと思われる。

　JSFにおけるUIコンポーネントのレンダラ（描画機能）は容易に差し替えが可能であるという特徴がある。つまり、もともとHTMLを出力するUIコンポーネントを、レンダラを入れ替えるだけで異なるフォーマットで出力することが可能になるのだ。Strutsでも、現在開発中のStruts-Facesライブラリを利用することで、今後、これらJSFコンポーネントとの相互運用が実現できるようになる。

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

　

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