2
アプリケーションの設計

サンプル・アプリケーションの設計には、複数の方法があります。そのうちの1つに、ページを連鎖させる方法があります。この場合、ページ1がページ2をコールし、ページ2がページ3をコールする...というようにしてページがつながっていきます。また、モデル-ビュー-コントローラ（MVC）の設計パターンを使用する方法もあります。セッション・ファサード設計パターンを使用する方法もあります。

この章の項目は次のとおりです。

2.1 設計の目標

アプリケーションを設計する際には、1箇所に変更を加えることによって他の部分に及ぼす影響を最小限に抑えること、または1箇所に変更を加えても他の部分に影響をまったく及ぼさないようにすることが望ましいといえます。それによって、次のことが可能になります。

アプリケーションを再設計することなく、機能を追加できます。
新しいクライアント・タイプ（たとえば、ワイヤレス・デバイス）を追加できます。
ビジネス・ロジックに及ぼす影響を最小限に抑えながら、クライアント・インタフェースを変更できます。
プレゼンテーション・データを変更することなく、ビジネス・ロジックを変更できます。
アプリケーションに及ぼす影響を最小限に抑えながら、データベース・スキーマまたはデータ・ソースを変更できます。
アプリケーション・パフォーマンスを最大化できます。

2.2 ページの連鎖

ページの連鎖による設計では、アプリケーションのページは順次リンクされています。つまり、ページ1にはページ2をコールするリンクがあり、ページ2にはページ3をコールするリンクがあります。以降のページについても同様です。次の図は、この連鎖を表したものです。

図2-1 ページの連鎖

画像の説明

ページごとに、生成方法が異なっていてもかまいません。たとえば、ページ1はプレーンなHTMLファイルで、ページ2はサーブレットによって生成し、ページ3はJSPによって生成するという設計も可能です。各ページの中には、リンクまたはフォーム要素（ユーザーがなんらかの値を入力する必要がある場合）があり、これを使用して、ユーザーは次のページに進むことができます。いずれの場合も、次のページへのリンクは各ページにハードコードされています。

関連項目
HTMLまたはその他のマークアップ言語の生成の詳細は、第5章「プレゼンテーション・ページの作成」を参照してください。

この設計のメリットは、簡単で理解しやすいことです。この設計は、規模が大きくなる可能性またはページが変更される可能性が少ない、小規模のアプリケーションを管理する場合に適しています。

この設計のデメリットは、クライアントのリクエストを処理する中心的な場所がないこと、およびページ間の移動が困難であることです。ページがアプリケーションから移動、追加または削除されると、あるページからコールされるコードを追跡して、それを別のページに移動したり、あるページを別のページからコールできるようにするために依存関係を変更する必要があるため、アプリケーションのメンテナンスが困難になります。

2.3 モデル-ビュー-コントローラ（MVC）の使用

アプリケーションのより望ましい設計方法は、モデル-ビュー-コントローラ（Model-View-Controller: MVC）の設計パターンを使用することです。MVCにより、アプリケーションを次の3つの部分に分割することで、そのアプリケーションを拡張したり、モジュール化することができるようになります。

ビジネス・ロジック: データの検索および操作を実装します。
ユーザー・インタフェース: アプリケーション・ユーザーに表示されるものを表します。
コントローラ: リクエストを正しいオブジェクトにルーティングします。

MVC設計パターンにより、アプリケーションをこれら3つの部分に分割することで、アプリケーションの他の部分に支障を及ぼすことなく、1つの部分を変更できます。これによって、複数の開発者が、相互に支障を及ぼすことなく、アプリケーションの異なる部分で同時に作業できます。各開発者は、個々の部分がアプリケーションで果たす役割を把握できます。たとえば、ユーザー・インタフェース部分には、ビジネス・ロジックを処理するコードを含めることはできません。逆の場合もまた同様です。

また、MVCを使用すると、アプリケーションをポートレットに変換したり、ワイヤレス・デバイスからアクセスできるようにすることも容易になります。

MVCの詳細は、次のWebサイトを参照してください。

http://java.sun.com/blueprints/patterns/MVC.html

MVCを使用するサンプル・アプリケーション

サンプル・アプリケーション1およびWebサービス・クライアントのサンプル・アプリケーションでMVCを使用します。サンプル・アプリケーション2では、セッション・ファサード設計パターンを使用します。

サンプル・アプリケーション1でのMVCの使用方法は、第II部「サンプル・アプリケーション1」を参照してください。

Webサービス・クライアント・アプリケーションでのMVCの使用方法は、第11章「アプリケーションでのWebサービスの有効化」を参照してください。

2.3.1 MVCのダイアグラム

図2-2にMVCアプリケーションの全体的な構造を示します。MVCアプリケーションは、クライアントからリクエストを受け取ると、次の手順でそのリクエストを処理します。

クライアントがリクエストを送信します。このリクエストはコントローラによって処理されます。
コントローラは、リクエストで指定されているアクションを確認して、そのアクションのクラスをチェックします。このクラスは、AbstractActionHandlerクラスのサブクラスになります。
コントローラは、クラスのインスタンスを作成して、そのインスタンスのメソッドを起動します。
インスタンスによってリクエストが処理されます。通常の場合、リクエストはJSPページに転送されます。
JSPページでは、そのアクションに適したEnterprise JavaBeansのインスタンスを取得し、アクションを実行するメソッドを起動します。
JSPページで、メソッドからプレゼンテーション用に戻されたデータを抽出します。

図2-2 アプリケーションのアーキテクチャ

 画像の説明

2.3.2 コントローラ

コントローラは、クライアントからのリクエストを最初に受け取るアプリケーションのオブジェクトです。アプリケーションのどのページのリクエストもすべて、最初にコントローラを通過します。

コントローラでは、リクエストを処理するために、それぞれのリクエストのタイプをクラスにマップします。たとえば、サンプル・アプリケーション1には次のようなマッピングがあります。

表2-1 サンプル・アプリケーション1のコントローラにおけるマッピング

アクション	クラス
`queryEmployee`	`empbft.mvc.handler.QueryEmployee`
`addBenefitToEmployee`	`empbft.mvc.handler.AddBenefitToEmployee`
`removeBenefitFromEmployee`	`empbft.mvc.handler.RemoveBenefitFromEmployee`

アクションは、コントローラに渡される問合せ文字列パラメータです。コントローラはリクエストを受け取ると、actionパラメータの値をチェックして、リクエストのクラスを確認します。それから、クラスのインスタンスを作成して、リクエストをそのインスタンスに送信します。

アプリケーションの作成時には、コントローラ・コード自体でマッピングをハードコードしたり、データベースまたはXMLファイルからマッピング情報が読み取られるようにコントローラを設定することができます。データベースまたはXMLファイルを使用する方が、柔軟性が高くなります。

サンプル・アプリケーション1では、マッピングはハードコードされます。

（Webサービスを介して、サンプル・アプリケーション2での操作を実行する）Webサービス・クライアント・アプリケーションでは、マッピングはコントローラ・サーブレットの初期化パラメータとして指定されます。サンプル・アプリケーション2では、MVC設計パターンは使用しません。

コントローラをアプリケーションにおける最初の接続ポイントとして使用することで、アプリケーションに機能を追加しやすくなります。新しい機能を実装する場合に必要な作業は、マッピングを追加して、新しいクラスを作成することだけです。

サンプル・アプリケーションでは、コントローラ・オブジェクトとしてサーブレットを使用します。アプリケーションの各ページには、このサーブレットへのリンクを設定します。

ページの連鎖による設計の場合は、他のページをコールしているページを追跡する必要があるため、ページの追加や削除が大変な作業になることもあります。一方、コントローラを使用すると、このようなページを連鎖させる作業から解放されます。

2.3.3 モデル（ビジネス・ロジック）

モデルは、ビジネス・ロジックを実装するオブジェクトを表します。このオブジェクトによってクライアント・データが処理され、レスポンスが戻されます。モデルには、データベースから取得したデータも含まれます。モデル内のオブジェクトには、Enterprise JavaBeans、JavaBeansおよび通常のJavaクラスを含めることができます。モデル内のオブジェクトは、ビューおよびコントローラによって起動されます。

コントローラによってリクエストが読み込まれた後、モデル内のオブジェクトによって、そのリクエストを処理する実際のすべての作業が実行されます。たとえば、問合せ文字列から値を抽出してリクエストが有効であるかを確認する作業、クライアントを認証する作業、トランザクションを開始する作業、データベースに問い合せる作業が実行されます。サンプル・アプリケーション1では、EmployeeManager Session BeanからEmployee Entity Beanをコールすることによって、データベースに問い合せて従業員の情報を取得します。

プレゼンテーション・データは、ビジネス・ロジックに含めてしまう場合がありますが、プレゼンテーション・データを分離して専用のファイルに入れる方がよい方法といえます。たとえば、プレゼンテーション・データをJSPファイルに書き込むことで、そのファイルでHTMLマークアップを編集したり、モデル・コードを変更することなくデータのフォーマットを変更することができます。それに応じて、ページのデータのフォーマットを設定できます。JSPファイルでは、メソッドがデータを取得する方法は指定しません。

データベース・アクセス

通常の場合、データベース内のデータの読取りと更新は、モデル内のオブジェクトによって実行されます。Enterprise JavaBeansオブジェクトを使用してデータベースにアクセスしている場合は、次の方法を選択できます。

Bean管理の永続性（BMP）を持つEntity Beanの使用。BMP Entity Beanを使用する場合は、データベースのデータの読取りと更新のためにコードを書き込む必要があります。
コンテナ管理の永続性（CMP）を持つEntity Beanの使用。CMP Entity Beanを使用する場合は、デプロイメント・ディスクリプタでBeanを構成します。

BMP Entity Bean: アプリケーションのデータベース・アクセス部分をBMP Entity Beanから分離する場合は、DAO（データ・アクセス・オブジェクト）を使用するようにしてください。BMP Entity Beanは、DAOクラスでメソッドを起動してデータベースにアクセスします。そうすることで、データベースに送信するSQL文を独立させることができます。

DAOを使用すると、データ・ソースの変更において柔軟性が得られます。データベースを更新する場合（たとえば、データベースの表の名前や構造を変更する場合）、アプリケーションの他の部分を変更することなく、データ・アクセス・オブジェクトでSQL文を更新できます。

サンプル・アプリケーション1では、BMP Entity BeanおよびDAOを使用します。DAOによって、データベースへの接続が設定され、必要なSQL文がデータベースに対して実行され、該当するデータが戻されます。

クリーンなモデルの作成方法の詳細は、Sun社のWebサイトのJava BluePrintsページおよびDesign Patterns Catalogページを参照してください。

http://java.sun.com/blueprints
http://java.sun.com/blueprints/patterns/catalog.html

CMP Entity Bean: EJBコンテナでデータベース・アクセスを管理する場合は、CMP Entity Beanを使用できます。デプロイメント・ディスクリプタ・ファイルを使用して、データベース内の表にEntity Beanをマップします。コンテナは、Entity Beanのフィールドを表内の列に対応付けます。

デプロイメント・ディスクリプタ・ファイルでは、Entity Bean間のコンテナ管理の関連性（CMR）を定義することもできます。CMRを使用すると、他のEntity Beanのデータに基づいた、特定のEntity Beanのデータを取得できます。

サンプル・アプリケーション2では、CMP Entity BeanおよびCMRを使用します。

関連項目
第10章「EJB 2.0の機能を使用するためのEJBの更新」

2.3.4 ビュー

ビューには、HTMLタグなどのプレゼンテーション・データおよびモデルから戻されたビジネス・データが含まれます。プレゼンテーション・データおよびビジネス・データは、リクエストに対するレスポンスとして、クライアントに送信されます。HTMLタグには、一般的に、データ、ユーザーが対話に使用するフォーム要素（テキスト・フィールド、ボタンなど）、および他のプレゼンテーション要素があります。

プレゼンテーション・データおよびビジネス・データは、異なるソースから取得します。ビジネス・データはモデルから取得し、プレゼンテーション・データはJSPファイルから取得します。このように、プレゼンテーション・データとビジネス・データは切り離しておきます。

ビジネス・データとプレゼンテーション・データのコーディングを別々に行うことで、別のクライアント・タイプをサポートできるようにアプリケーションを拡張することが容易になるという利点が得られます。たとえば、ワイヤレス・デバイスをサポートできるように、アプリケーションを拡張する必要がある場合があります。ワイヤレス・デバイスでは、その端末に応じて、WMLまたはその他のマークアップ言語を読み取ります。プレゼンテーション・データをビジネス・ロジックに埋め込んでいると、どのタグがどのクライアント・タイプのものであるかを追跡するのが困難になります。プレゼンテーション・データとビジネス・データを切り離しておくと、同じビジネス・オブジェクトを新しいプレゼンテーション・データで再利用できます。

また、アプリケーションの新規クライアントの中には、データをグラフィカルに表示しないものもあります。このような場合、表示タグを取得する必要はありません。どのような方法であっても、処理できる結果を取得できればよいことになります。

プレゼンテーション・データ用のファイルには、アプリケーションのモデル側のオブジェクトを起動するコード以外には、ビジネス・ロジック・コードを含めないでください。それによって、クライアント・コードを変更することなく、ビジネス・ロジックおよびデータベース・スキーマの実装を変更できます。

サンプル・アプリケーションでのクライアント・タイプには、ブラウザ、各種のワイヤレス・デバイス、非Webクライアント（たとえば、他のアプリケーション）、SOAPクライアントなどがあります。ビューを変更するだけで、クライアントを追加したり、クライアントに対するデータの表示方法を変更することができます。データには、HTML、WMLまたはその他のマークアップ言語を使用できます。

サンプル・アプリケーションでは、すべてのプレゼンテーション・コードをJSPファイルに含めます。このJSPファイルによって、リクエストを処理するEJBおよびサーブレットをコールします。

2アプリケーションの設計