再びStruts開発のサポートをしていて感じたことについて、前回の「Struts開発での考察」に続いて報告です。
今回の開発サポートでは、Strutsでの開発経験がほとんどなく、Struts初心者にいかにすばやく開発を進めるかを考えました。Strutsを学ぶのは簡単ではないというのは、異論がないと思います。でも仕事としてはStrutsを使いこなすのが目的ではなく、客が動かすシステムそのものが全てなので、難しいことは抜きにいかに早く実装するかを重視してみました。

初めにヒアリングした内容では、こんな感じです。開発メンバーはオブジェクト指向なんてあんまり知りません。。。

Validatorは難しいし、使い勝手が悪かったので使わない

Validatorは非常に強力な妥当性検証機能だと信じていたのですが、こちらの開発チームでは「習得するの事が難しい上に、ちょっとチェックになると対応できないので、初めから使わないで統一する。」ということでした。
言われてみれば、あのValidatorを習得するのは面倒ですし、使い慣れていない人には、設定ファイルで記述することでJavaScript、サーバーサイドの両方でチェックされるというありがたみが分かってもらえません。
思い切って自前のJavaScriptでチェックします。そのための基本的なチェック関数はライブラリ資産としてあるので対して苦ではありません。

妥当性検証はJavaScriptのみ

上記と重複しますが、サーバーサイドでの入力チェックは、DBを使用するケースでしか使いません。未入力チェックや、桁数チェックなどのJavaScriptで可能なチェックはクライアントでしか行いません。サーバーサイドでのチェックを行わないことは、即セキュリティホールに繋がりそうなのですが、社内イントラ内のWebシステムなので、セキュリティホールを突いた攻撃など考慮する必要がないとのことでした。
クロスサイトスクリプティングや、SQLインジェクションは、外部公開するわけではないから気にしないとのことです。もちろん画面描画が崩れないようにサニタイジングする必要はあります。

ページ（画面）単位でActionFormを1つ作成

ページ内には1つだけのformタグを配置し、ActionFormは1ページ（画面）につき1つだけしか作成しません。
このページから（主にボタン毎に）複数のアクションイベントが発生しますが、それはJavaScriptを使って、formタグのactionパスを切り替えてしまいます。

1ページにつき発生するActionは複数

1ページから発生するActionは複数あります。しかしそれらのActionに関連付けられたActionFormは全て同一です。
例外的に、linkをクリックしてGETでリクエストするような場合は、formタグとは関係なくなるので、別のActionFormを定義します。

Actionの実行結果は、ActionFormとDTOでJSPに渡す

例えば検索した検索結果の一覧表はDTOで表示します。（DTOがListのフィールドを持ち、List内に1行分の別のDTOを保持するようなつくりです。）
JSP内のテキストボックスなどのform部品のデータは、ActionFormに設定します。たたし、selectタグのoption要素はDTOで保持します。(DTOがListのフィールドを持ち、List内に、option1つぶんのLabelValueBeanを保持）
これは前回の記述で挙げた、「ActionFormはフォームデータの入れ物」に従います。ActionFormに検索結果の一覧を入れたりはしません。
実装の効率性を考慮したら、DTOはMapやListなどのコレクションを使って代用し、JavaBeanを作らなくてもよいかと思いました。JSPではELを使うので、コレクションのままでもアクセスしやすいと思ったからです。
しかしながら静的な型チェックを重視して不採用になりました。変更に強く、実装の効率性を考慮したらMapとListで十分だと派思うのですが。。。

Actionからビジネスロジック実装クラスを呼び出す

Actionからビジネスロジックを実装したクラスを呼び出します。必然的にActionのexecuteメソッドはスカスカになり、ビジネスロジック実装クラスの呼び出しフローだけになります。
1ページに対して1つのビジネスロジック実装クラスを作成し、そちらに構造化プログラミングライクにロジックを実装します。兼DAOです。
1つである必要はないのですが、ルールとして1ページにつき1つとなりました。（考えてクラス分けすることが出来ないので、ルールで決め込むしかないのです）
今回、Actionは1イベントにつき1つになるように、通常のActionから派生して作成しましたが、DispatchActionや、MappingDispatchActionを使用すれば、Actionも1ページにつき1つになると思います。
ビジネスロジックも1イベントにつき、1つ作成したほうが長すぎずによいとも思われたのですが、複数のイベント間で共通的な処理を記述するために1つのビジネスロジッククラスとしました。このあたりで結構無茶が出てきています。

カスタムタグはstruts-htmlと、JSTLを使用

今となっては、struts-beanとかstruts-logicは使う必要がないので、JSTLを使用することにしました。

画面	リクエスト/レスポンス	イベント	処理
ページ1	ActionForm1 DTO1A	Action1A	ビジネスロジック1
	ActionForm1 DTO1B	Action1B
	ActionForm1 DTO1C	Action1C

こんな感じで開発を進めています。ビジネスロジックの構成が変で仕方ないです。ビジネスロジックの構成が画面の構成に依存しているのが絶対的におかしいのですが、画面(UI)抜きでビジネスロジックをモデリングしてもらうことを、なかなか理解してもらえないです。

Strutsを使った開発では、色々な実装パターンがあると思いますが、私の会社ではプロジェクトによって結構バラバラです。いろんなパターンを考えて検証していきたいと思います。