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

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

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

　連載第1回の『1分でWebアプリを作れるEclipseプラグイン「Dolteng」』では、Webアプリケーション開発に非常に便利なEclipseプラグインである「Dolteng」の機能を使用して、「SAStruts」（後述）のプロジェクトを自動生成しました。

　このDoltengで自動生成されたプロジェクトとソースはテンプレートとしての基本的機能しか作成されていません（Doltengも進化中であり、このテンプレート自体が強化されていくことがあるかもしれません）。しかし、何もないところからプログラムを開始するのと、すでに動くものがあり少しずつ修正を加えて作っていくのでは苦労がまったく違います。

　これ以降の連載では、これらを修正・カスタマイズしていくために、Doltengで生成されたソースコードを中心に解説していきたいと思います。今回は、Doltengで生成されたプロジェクトの構成を見ていきながら、SAStrutsとStrutsでのアクション（Actionクラス）とフォーム（Formクラス）における設定方法の違いを中心に、SAStrutsについて説明します。

Super Agile Struts via kwout

　なお今回の記事は、前回作成した環境を使用します。まだ前回の記事を読んでいない人は、前回記事からご参照ください。

Struts開発者の悩みを解決する「SAStruts」とは？

　2008年11月現在まで多くのJavaのWebアプリケーションに採用されてきたStrutsですが、その高い機能性にもかかわらず、以下のような問題点を指摘されることも多くあります。

• 画面を作るたびに設定ファイルに書き加える
• form-beanを修正しても設定ファイルを書き加える
• 新しい遷移先が増えても設定ファイルを書き加える
• 変更があれば、Javaのソースだけではなく、設定ファイルもすべて見直さなければならない

　Strutsそのものの解説は、以下の記事が参考になると思います。この連載をより深く理解するために、ぜひ参照しておいてください。

Webアプリの常識をJSPとStrutsで身につける via kwout

　SAStrutsは、そんなStrutsの設定ファイルの煩わしさから開発者を解放して、超俊敏なStrutsでのWebアプリケーション開発を実現してくれるのです。

　SAStruts（Super Agile Struts）は前回のDoltengと同じく、オープンソースプロジェクトSeasarのプロダクトの1つで、Strutsフレームワークにうすい膜をかぶせて、より便利に超俊敏に使えるようにしたWebアプリケーションフレークワークです。Strutsに慣れた開発者なら違和感なく扱えると思います。

SAStrutsとStrutsのアーキテクチャの違い

　Strutsの場合、すべての設定情報がXMLファイル「struts-config.xml」に集まっていて、Strutsは常にstruts-config.xmlの設定を参考にActionクラスを呼び出します。このため、開発者の作ったソースとの連結設定をすべて書かなければなりません。これが、Struts開発でのボトルネックや開発者のストレスの一因となっていると思います。

図1　Strutsのアーキテクチャ

　SAStrutsはStrutsを内包していて、処理の流れの管理はStrutsが行っていて、基本的には変わっていません。しかし、struts-config.xmlの部分がすべてSAStrutsによってソースコードから自動生成されるので、設定ファイルに開発者が手を煩わされることはありません。

図2　SAStrutsのアーキテクチャ

　また、ActionクラスがStrutsと切り離されてPOJOとして定義できるので、テストやコンポーネントの再利用なども非常に楽になっています。

SMART deployの推奨パッケージ構成

　今回は、Seasar 2.4の「SMART deploy」で推奨している「パッケージ構成」を使用して、DI（依存性の注入）を行います。SMART deployの標準パッケージ構成は、ルートパッケージを決めて、その下にクラスに持たせる種別ごとのパッケージを置きます。SMART deployについては、次回詳細に解説します。

　今回DIされているコンポーネントで分かりやすいものは、後述する「deptForm」「deptService」です。deptFormとdeptServiceは宣言のみで、どこからも値を設定するロジックが定義されていませんが、ActionクラスのメソッドがSAStrutsから呼び出された時点で自動でコンポーネント（ServiceクラスやFormクラス）がDIされて、すでに使用できる状態です。

　具体的な内容は、次ページからSAStrutsのパッケージ構成を見ながら説明します。分かりやすく説明するため、この標準パッケージ構成を今回の規約として話を進めるので、実際にはカスタマイズしたり、新たな設定を行えば変更できることもありますが、厳密には違う表現の部分があるかもしれませんが、SAStrutsを始めるための記事としてご配慮ください。

　本来のSeasar2の機能をフルに使用するればさまざまなカスタマイズが出来るので、そちらは別の機会に紹介できればと思います。