StrutsのXML地獄から開発者を解放するSAStruts：Java初心者が超俊敏にWebアプリを作る方法（2）（2/3 ページ）

Eclipseプラグイン「Dolteng」のScaffoldという自動生成機能やSeasar 2.4のHOT deploy機能を利用して、DBの参照・更新・削除ができるSAStrutsのWebアプリを作ります。Java初心者だけでなくStrutsに慣れた開発者も必見です

[新田智啓，株式会社パワーエッジ]

SAStrutsプロジェクトのパッケージ構成

図3　SAStrutsプロジェクトのパッケージ構成

　それでは、前回作成したSAStrutsプロジェクトのパッケージ構成から見てみましょう。パッケージは、右の図3のようになっているはずです。

ルートパッケージ.action
　　　　　　　　.condition
　　　　　　　　.dto
　　　　　　　　.entity
　　　　　　　　.form
　　　　　　　　.service

　では、各パッケージについて簡単な概要を説明していきます。

StrutsのActionに該当する「action」パッケージ

　StrutsのActionクラスに該当するクラスを格納します。ここに配置するクラスは「XxxxAction」という命名規約である必要があります。また、このパッケージに配置されるクラス名がWebブラウザでアクセスされる際のURLにそのまま使用されます。

　詳しい説明は、後ほどStrutsとの比較の部分で説明します。現時点では、Doltengで作成された「DeptAction」クラスが配置されているはずです。

データベースにアクセスする条件を設定する「condition」パッケージ

　データベースにアクセスする条件を設定するためのクラスを格納します。今回は使用しません。

データオブジェクトを格納する「dto」パッケージ

　Formクラスやentityパッケージ以外のデータオブジェクトを格納します。ここに配置するクラスは、「XxxxxDto」という命名規約である必要があります。

テーブルとマッピングするオブジェクトを格納する「entity」パッケージ

　データベースのテーブルとマッピングするオブジェクトを格納します。このクラスのメンバ変数はデータベースと同名の必要があります。現時点では、Doltengで作成された「Dept」クラスが配置されているはずです。

StrutsのFormに該当する「form」パッケージ

　StrutsのFormクラスに該当するクラスを格納します。ここに配置するクラスは「XxxxForm」という命名規約である必要があります。現時点では、Doltengで作成された「DeptForm」クラスが配置されているはずです。

業務ロジックやエンティティを操作する「service」パッケージ

　さまざまな業務ロジックやエンティティを操作するクラスを格納します。ここに配置するクラスは「XxxxService」という命名規約である必要があります。現時点では、Doltengで作成された「DeptService」クラスが配置されているはずです。

JSPファイル配置フォルダ

　パッケージではありませんが、JSPを置くフォルダも説明しておきます。JSPファイルは「/src/main/webapp/WEB-INF/view」フォルダ配下に格納します（デフォルト）。「view」フォルダの下に、Actionクラス名から「Action」を除いて小文字にした文字列を名前にしたフォルダを配置し、その中に「jsp」フォルダを入れておきます。

　現時点では、Doltengで作成された機能は一覧と参照、更新、作成の4つの画面のため、「DeptAction」の「Action」を除いて小文字にした「dept」フォルダが作成され、その配下に「list.jsp」「show.jsp」「edit.jsp」「create.jsp」が配置されているはずです。詳細は後述します。

ひと目で分かるパッケージ構成

　小さなアプリケーションであれば、上記のようなパッケージ名／クラス名のルール（命名規約）を守るだけで、「画面のコントロールなのか」「業務的な処理であるか」「データベースのエンティティオブジェクトなのか」などがひと目で分かる基本的できれいなパッケージ構成が出来上がります。

図4　各パッケージの中身

Strutsでの設定例を見てみると……

　ここからは具体的に、StrutsとSAStrutsでの設定の仕方を比較します。今回見ていくクラスはDeptActionクラスとDeptFormクラスです。

　Doltengで自動生成された画面制御処理の設定を、Strutsの「struts-config.xmlで同等に設定すると、以下のようになります（ルートパッケージは、前回記事と同様に「jp.ne.sastruts.start」としています）。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　ここで、必要となる設定は以下の3つです。

1. BeanであるFormの定義
2. Actionのクラスの定義（利用するFormの設定）
3. Actionから画面の遷移先の定義

　これらは画面追加や画面のフォームの追加、画面の遷移先の追加のたびに設定しなければならず、設定が肥大化して「設定ファイル地獄」「XML地獄」と呼ばれたりします。

　また、チームで開発している場合、同じ設定ファイルを修正することが多々あるため、CVSやSubversionでファイルバージョン管理などを行っていても競合を起こしたり、ファイルバージョン管理ツールがXMLファイルをうまく解析できず、おかしな形でマージされてしまう問題が起きたりします。

　CVSやSubversionなどのファイルバージョン管理ツールについて詳しく知りたい読者は、下記記事を参照してください。

ユカイ、ツーカイ、カイハツ環境！ via kwout

では、XMLを使わずにどうやって設定を行うのか？

　SAStrutsでは、クラス名やパッケージ名のルール（命名規約）やアノテーションで多くの情報を設定します。アノテーションで設定する部分はわずかで、覚えるべき基本のアノテーションは、以下の3つしかありません。

• @Execute
• @ActionForm
• @Resource

　では、Strutsの設定ファイルで必要な上記3つの情報を、SAStrutsではルール（命名規約）とアノテーションでどのように設定しているのかを具体的に見ていきましょう。

【1】BeanであるFormの定義

　SAStrutsでは、定義文を書く必要はありません。「form」パッケージの配下に「XxxxForm」という命名規約のクラスを作っているだけで自動的にFormクラスで使用するものとして定義されます。

　次ページでは、引き続きSAStrutsでの情報設定の仕方について解説します。