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

入力妥当性チェック機能

　不特定多数のユーザーが利用するWebアプリケーションでは、入力データの妥当性検証は欠かすことのできない処理の1つだ。しかし、この検証処理は定型的であるにもかかわらず、実装によってはコーディングが冗長になる一因ともなり、従来、アプリケーション開発者を悩ませてきた大きなテーマでもあった。

　そこで、ASP.NET／Strutsではいずれも専用のValidator機能を用意している。Validator機能を利用することで、ASP.NET／Strutsでは妥当性検証ロジックを限りなくプログラム・レスで記述することができる。ただし、以下をご覧いただければ分かるように、両者のアプローチはそれぞれにまったく異なるものだ。

　まず、Strutsでは「プラグイン」と呼ばれる拡張機能を利用することで検証機能を実現している。

　Validatorプラグインに関する詳細は、拙稿「Validatorによる妥当性検証の実現」などを参照いただくとして、Validatorによる検証機能はいかにもStruts的だ。Strutsにおいて、基本的な検証のルールは、validator-rules.xmlというファイルであらかじめ用意されている。必須検証や文字列長検証など、基本的なルールはこのファイルに用意されているし、もしもカスタムの検証ルールを追加したいという場合にも、このファイルに対して定義を追加すればよい。

　個別ページの検証機能については、各画面の検証定義を「検証情報ファイル」に記述しなければならない。Strutsコントローラ（アクション・サーブレット）は、ユーザーからリクエストを受けたタイミングで、検証情報ファイルの定義に基づいて、フォーム上の各値を検証するというわけだ。このため、前編でも紹介したコンフィグレーション・ファイル同様、検証情報ファイルはアプリケーション規模に比例して増大する。

　一方、ASP.NETにおける検証機能の実装もまた、いかにもASP.NET的だ。

　ASP.NETでは「検証サーバ・コントロール」と呼ばれるサーバ・コントロールによって、必須／数値範囲／フォーマット検証などの基本的な検証機能を提供している。検証コントロールを利用するには、基本的にサーバ・コントロールのプロパティ値に対して、検証値や検証対象、エラー・メッセージなど必要な検証パラメータを渡すだけでよい。詳細は、拙稿「Visual Studio .NETでプログラム・レス開発を学ぶ」などを参照いただくとして、実にそのほかには何ら設定もコーディングも行う必要はないのだ。

　Visual Studio .NETなどのIDEを利用しているならば、コントロールをドラッグ＆ドロップして、プロパティ・シートによる値設定を行うだけだ。独自の検証ルールを追加したいという場合にも、CustomValidatorコントロールが用意されているので、Webフォームにコントロールを配置したうえで、検証ロジックはイベント・ハンドラに記述すればよい。

　ASP.NETでは、すべてが個々のページ内で完結するという仕組みが基本なのだ。複数の設定ファイルの整合性を意識する必要があるStrutsのValidatorに比べれば、ASP.NETの検証コントロールは、はるかに直感的な実装に向いているということができるだろう。

　もっとも、だからといって、ASP.NETの検証コントロールが至上の解というわけでもない。前編の「フレームワークの内部構成」の項でも触れたように、Strutsでは単一コントローラを前提に、設定ファイルからアプリケーションに関する一連の情報を取得してくるのが基本だ。つまり、アプリケーションが大きくなった場合にも、比較的、情報を1か所で集約管理しやすいという利点がある。

　例えば、エラー・メッセージ1つをとってみても、Strutsではリソース・ファイルで一元的に管理されているので、各フォーム単位の設定からは、最低限の項目名や検証パラメータを明示するだけでよい。一方のASP.NETでは、検証コントロール個々のErrorMessage属性によって制御しているので、メッセージを一元管理するにも自ら専用のPage派生クラス（またはHttpHandlerクラス）などで、メッセージ・リソースを動的に加工／取得する仕組みを追加する必要がある（具体的な方法については、後日公開予定の.NET TIPS「検証コントロールのエラー・メッセージを一元管理するには？」で紹介したい）。

アプリケーションの構成ファイル

　前編でも解説したように、ASP.NET／Strutsではいずれもアプリケーションの構成を管理するために、XMLベースの設定ファイル（ASP.NETでは「構成ファイル」、Strutsでは「コンフィグレーション・ファイル」と呼ばれる）を用意している。

　それぞれがアプリケーション構成に占める位置付けこそ異なるものの、いずれもアプリケーション規模が大きくなれば肥大化する可能性をはらんでおり、ひいては、それがアプリケーションそのものの保守性低下につながることにもなる。こうした問題を避けるために、ASP.NET／Strutsでは、構成ファイルを分散管理するための方法を提供している。

■上位フォルダの設定を継承するASP.NETの構成ファイル

　ASP.NETの動作を規定する「構成ファイル」は、

• マシン構成ファイル（machine.config）
• アプリケーション構成ファイル（web.config）

の2つに大別される。machine.configはサーバに1つしか配置できないが、web.configはアプリケーションごと、またはアプリケーション・フォルダ配下のサブフォルダ単位に（フォルダ階層ごとに）配置することができる。すなわち、以下のようなイメージだ。

ASP.NETの構成ファイルの配置

machine.configはサーバに1つしか配置できないが、web.configはアプリケーションごと、またはアプリケーション・フォルダ配下のサブフォルダ単位に（フォルダ階層ごとに）配置できる。

　構成ファイル（web.config）が異なる階層のフォルダに配置されており、それぞれのフォルダにある構成ファイルに同一の項目が設定されている場合には、最下層の構成ファイルの設定が優先的に適用されるようになっている。また、構成ファイルに設定されていない項目でも、より上位の階層に配置された構成ファイルにその項目の設定がある場合には、その上層の構成ファイルから「設定の継承」が行われて適用されるようになっている。

　ASP.NETは、このように「構成ファイルを階層構造的に配置する」ことで、アプリケーション（またはサブフォルダ、ページ）単位の柔軟な設定を可能にすると同時に、設定という行為そのものを簡略化できる。

　ただし、こうした管理上の柔軟性は常に良いことばかりではない。より上位のサーバ管理者が設定していた項目を、下位のアプリケーション管理者が想定外に変更してしまったとしたらどうだろう。思わぬ設定が当該アプリケーションのみならず、アプリケーションが属するサーバ全体のセキュリティ・ホールの原因となることもあるのだ。しかし、ASP.NETではこのような場合に備えて、設定項目の単位に設定権限を制約するための手段を提供している。詳細については、別稿「アプリケーション個別の構成ファイルの変更を禁止するには？」にて詳説しているので、併せて参照いただきたい。

■モジュール分割に分散可能なStrutsのコンフィグレーション・ファイル

　一方のStrutsでは、バージョン1.1からアプリケーションを分割し、「モジュール」という単位で分割管理することが可能となった。コンフィグレーション・ファイルもまた、このモジュールの単位に分散管理することができる。モジュールを定義するには、デプロイメント・ディスクリプタ（web.xml）の定義で、以下のように記述すればよい。

<servlet>   <servlet-name>action</servlet-name>   <servlet-class>     org.apache.struts.action.ActionServlet   </servlet-class>   <init-param>     <param-name>config</param-name>     <param-value>/WEB-INF/struts-config.xml</param-value>   </init-param>   <init-param>     <param-name>config/wings</param-name>     <param-value>       /WEB-INF/struts-config-wings.xml     </param-value>   </init-param>   <load-on-startup>1</load-on-startup> </servlet>

Strutsのデプロイメント・ディスクリプタ（web.xml）の定義（抜粋）

このファイルでは、無名（default）モジュールとwingsモジュールの2つを定義している。各モジュールで利用するコンフィグレーション・ファイルもここで指定可能だ。

　上の例では、無名（default）モジュールとwingsモジュールの2つを定義している。モジュールを利用する場合、アプリケーション・ルート配下の「.jsp」ファイルもまた、モジュール名と同名のディレクトリに配置する必要がある。これによって、コンフィグレーション・ファイルの肥大化を防ぐことができるのみならず、モジュール単位の並行開発も可能になるというわけだ。

　ただし、個々のモジュールの関係はあくまで並列であって、ASP.NETのように設定ファイル同士に継承関係を持たせることはできない。また、構成ファイルの記述そのものを減らすための施策としては、次期バージョン1.2で「ワイルドカード・マッピング」が提供される予定である。

<action path="/*Action"     type="net.wings.{1}Process" name="{1}Form" scope="request">   <forward name="success" path="/{1}.jsp" /> </action>

Strutsの次期バージョン1.2で利用可能になる「ワイルドカード・マッピング」

この記述はコンフィグレーション・ファイル「struts-config.xml」より抜粋したもの。ワイルドカード・マッピングにより、構成ファイルの記述を簡略化できるようになる。1行目の「*」部分にマッチングした文字列が、プレイスホルダである「{1}」に埋め込まれる。

　

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

　

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