Struts フレームワークおよび Model/View/Controller の設計パターン

Struts はオープン・ソース・ソフトウェアのフレームワークの 1 つで、 Web アプリケーションの作成に役立ちます。このフレームワークは、 Java™ Bean、Java サーブレット、JavaServer Pages (JSP)、XML などの標準テクノロジーを利用します。 Struts は、Model 2 (Model/View/Controller (MVC) の設計パターンのバリエーションの 1 つ) のアプローチに基づいた、アプリケーション・アーキテクチャーを推進します。

Struts を使用して作成すると、複雑な Web アプリケーションでも保守がしやすくなります。 Struts を使用すると、拡張やデバッグが容易になり、構造が分かりやすくなります。

Struts の最も重要な部分は MVC スタイルのコントローラーで、モデルおよびビューを提供する他のテクノロジーと統合されます。モデルについては、Struts は JDBC や EJB などの標準データ・アクセス・テクノロジー、および Hibernate、iBATIS、Object Relational Bridge などの多数のサード・パーティー・パッケージと相互作用します。ビューについては、Struts は JSP Standard Tag Library (JSTL) および JavaServer Faces (JSF) を含む JSP だけでなく、Velocity Templates、XSLT などのプレゼンテーション・システムともよく協調して機能します。

Struts は、The Apache Software Foundation (ASF) によって推進されています。 Struts の詳細については、次の Web サイトをご覧ください。

http://struts.apache.org/struts/index.html

以下のセクションでは、Model/View/Controller の設計パターンおよび Struts テクノロジーについて説明します。

MVC 設計パターンの概要
Model 1 と Model 2
Struts における Model 2 の実装
MVC 設計パターンの利点

MVC 設計パターンの概要

J2EE アプリケーション・プログラミングでは Model 2 の別名でも知られる Model/View/Controller (MVC) の設計パターン (model-view-controller design pattern) は、プログラミング向けの設計パターンとして定評があります。テーブル 1 に、MVC の 3 つのメイン・コンポーネントを要約します。

表 1. MVC コンポーネントの要約
	目的	説明
モデル	データの保守	ビジネス・ロジックと 1 つ以上のデータ・ソース (リレーショナル・データベースなど)。
ビュー	データの全体または一部の表示	モデルに関する情報をユーザーに表示するユーザー・インターフェース。
コントローラー	モデルまたはビューに影響するイベントの処理	ユーザーがアプリケーションと対話するためのフロー制御機構手段。

Model 1 と Model 2

Model 1 アーキテクチャーと Model 2 アーキテクチャーは、いずれもコンテンツの生成 (ビジネス・ロジック) をコンテンツの表示 (HTML フォーマット設定) から分離します。 Model 2 は、要求処理の大半が実行される場所が Model 1 と異なります。つまり、JSP ページ内ではなく、コントローラーによって処理が実行されます。

図 1 に示すように、JSP Model 1 アーキテクチャーでは、着信要求の処理とクライアントへの応答が JSP ページだけで行われます。

図 1. JSP Model 1 アーキテクチャー

この 3 層アーキテクチャーでは、JSP ページおよび JavaBean がアプリケーション・サーバーに、データ・ストアおよびビジネス・ロジックがデータ・サーバーにあります。

ブラウザーが JSP ページに要求を送信します。
JSP ページが Java Bean と通信します。
Java Bean がデータベースに接続されます。
JSP ページがブラウザーに応答します。

図 2 に示すように、JSP Model 2 アーキテクチャーでは、サーブレットが要求を処理し、JSP ファイルで使用される Bean またはオブジェクトを作成し、要求を転送します。

図 2. JSP Model 2 アーキテクチャー

この 3 層アーキテクチャーでは、サーブレットおよび JSP ページがアプリケーション・サーバーに、データ・ストアおよびビジネス・ロジックがデータ・サーバーにあります。

ブラウザーがサーブレットに要求を送信します。
サーブレットはデータベースに接続された Java Bean をインスタンス化します。
サーブレットが JSP ページと通信します。
JSP ページが Java Bean と通信します。
JSP ページがブラウザーに応答します。

テーブル 2 は、Model 1 と Model 2 のどちらがより適切であるかを判断するための基準を示しています。

表 2. Model 1 または Model 2 の使用のガイドライン
基準	Model 1	Model 2
Web アプリケーションのタイプ	シンプル	複雑
開発者による作業の種類	高速プロトタイピング	変更および保守の対象となるアプリケーションの作成
作業の担当者	ビューとコントローラーを同じチームで処理	ビューとコントローラーを別のチームで処理

Struts における Model 2 の実装

Struts における Model 2 の実装では、アクション・サーブレットと呼ばれる特定タイプのサーブレットと、1 つ以上のアクション、およびアクション・マッピングを使用して、コントローラーを実装します。また、フォーム Bean と呼ばれる特定のタイプの Java Bean も使用します。図 3 に示すように、実行時の Web サーバーには、Model 2 の Web アプリケーションのビュー・コンポーネントとコントローラー・コンポーネントの両方が含まれており、第 3 層 (通常は Web サーバーの外部にある) にはモデルが含まれています。

図 3. Struts フレームワーク: Model 2 アーキテクチャー

このダイアグラムは、 Model/View/Controller 原理を使用して設計されたアプリケーションの構造を示しています。

テーブル 3 は、MVC コンポーネントへの Struts の寄与を示しています。

表 3. モデル、ビュー、およびコントローラーへの Struts の寄与
コンポーネント	寄与
モデル	直接提供なし。ただし、Struts のアクションと構成ファイルは、モデル・コンポーネントが呼び出されるような状況を制御する的確な方法を提供します。
ビュー	Java クラス org.apache.struts.action.ActionForm。これをサブクラス化して、フォーム Bean を作成します。この Bean は、実行時に次の 2 とおりの方法で使用されます。 JSP ページは、表示用の関連 HTML フォームを準備するときに、Bean にアクセスします。この Bean にはフォームに入れる値が含まれます。これらの値は、ビジネス・ロジック、あるいは前のユーザー入力から提供されます。 Web ブラウザーからユーザー入力が戻されると、Bean はこの入力を検証し、ビジネス・ロジックで使用するため、または (検証が失敗した場合は) 続いて再表示するため、入力を保持します。使いやすく、かつ情報隠蔽という意味において、強力な多数のカスタム JSP タグ。 Page Designer は、フォーム Bean について多くの情報を必要としません。例えば、Bean 名および特定の Bean の各フィールド名で十分です。
コントローラー	Struts のアクション・サーブレットは、デプロイメントの際に提供されるルール・セットに従ってランタイム・イベントを処理します。これらのルールは Struts 構成ファイルに含まれており、サーブレットがビジネス・ロジックから受け取るあらゆる結果に対してどのように応答するかを指定します。制御のフローを変更する場合は、構成ファイルを変更するだけですみます。 Struts には、org.apache.struts.action.Action という Java クラスも用意されています。Java 開発者は、これをサブクラス化して「アクション・クラス」を作成します。実行時に、アクション・サーブレットは「アクションを実行する」ように指示されます。これはサーブレットが、インスタンス化された各アクション・クラスの `execute` メソッドを呼び出すことを意味します。`execute` メソッドから戻されるオブジェクトは、次にどのアクションにアクセスするか、またはどの JSP ファイルにアクセスするかをアクション・サーブレットに指示します。再利用を促進するには、アクション・クラスにビジネス・ロジックを組み込むのではなく、アクション・クラスからビジネス・ロジックを呼び出します。

MVC 設計パターンの利点

動的 Web アプリケーションの開発に対する Model/View/Controller 分割には、複数の利点があります。

開発作業をある程度分散できるので、Web アプリケーションの一部についてインプリメンテーションを変更しても、他の部分を変更する必要はありません。ビジネス・ロジックを作成する開発者は、制御のフローを作成する開発者から独立して作業でき、Web ページの設計者は開発者から独立して作業することができます。
担当する作業をより簡単にプロトタイプ化できます。例えば、次のようなことが可能になります。
1. 複数のワークステーション・ベースのプログラムにアクセスするプロトタイプ Web アプリケーションを試作できます。
2. ユーザーのフィードバックに応じてアプリケーションを変更できます。
3. 同じプラットフォームまたは別のプラットフォームに実動レベルのプログラムを実装できます。
プログラム自体の作業以外に必要となるのは、構成ファイルまたはネーム・サーバー・コンテンツの調整のみです。他のソース・コードの調整は不要です。
ビューはモデルから分離されており、コントロールはプラットフォームとユーザー・カテゴリーに対応して調整可能であるため、ユーザーはより容易にレガシー・プログラムをマイグレーションすることができます。
さまざまな場所に分散したさまざまなテクノロジーからなる環境を維持できます。
MVC の設計は組織的に構成されているため、(より大きなアプリケーションを構築する) スケーラビリティー、および (タスクのより明確な分離で可能になった) 変更と保守に対する容易性という優れたサポートを提供できます。

フィードバック