Strutsを使ったWEBアプリの設計についてのいくつかのメモ

入力用のJavaBeanと出力用のJavaBeanは別々に作る。
出力用のJavaBeanは画面ごとに作る。
入力用のJavaBeanは業務ロジックごとに作る。
入力用のJavaBeanはインターフェースと実装に分けて作る。
画面Ａが業務ロジックfooと業務ロジックbarの入力になりうる場合、画面Ａに紐付く出力用JavaBeanは、業務ロジックfoo、barの入力用JavaBeanインターフェースを実装する。
出力用JavaBeanは決められた属性名(viewとか)とforward名でHttpServletRequestに突っ込んでおく。
入力エラー時の画面再表示がめんどくさいかも…

入力用のJavaBeanと出力用のJavaBeanはひとつにする。
入出力用のJavaBeanは画面ごとに作る。
業務ロジックごとに期待する入力値のインターフェースだけ作っておいて、各JavaBeanはそれを実装。
複数の画面からの入力がある業務ロジックに対して、複数のURLを定義する必要があるのが難点か…Strutsに手を入れてタグで入力クラスを定義しないようにすればいいかな？RequestProcessorを拡張すれば「１つのURLに入力用JavaBean(ActionForm)は１つ」をなくせるかも。

１つの業務ロジックに対して１つのURLを定義する。
遷移先JSPは、すべてglobal-forwardsで定義してしまう。
- 業務ロジック中でも「○○画面に遷移する」というのを意識する。「設定ファイルを変えるだけで遷移先がころころ変わる」という設計は難しいし、そういう要件もない。
出力用JavaBeanから、一意にActionForwardが取得できるようにする。(クラス名をforward名にしてしまうとか)
遷移元画面を知るには、業務ロジックに遷移するURLを分けるか、遷移する際に遷移元画面を渡すようにする。<html:form>タグを改造して、<form>〜</form>を展開するときに画面名を自動的に渡す事が出来るようにすると便利だと思う。
- 画面ごとに異なるJavaBean(ActionForm)が入力されてくるなら instanceof で遷移元がわかるか。
出力用JavaBean(?)は、レスポンスの種類(~~text/html、text/plain~~ JSPにするか、独自にレスポンスを処理するか。)に応じて、インターフェースを定義しておく。
- JSPに遷移しない場合は、HttpServletResponceを出力用クラスに渡して、あとは出力用クラスに処理させる。
前画面に戻る処理は基本的にスタックを活用。出力用JavaBeanをスタックにつんでおく。

Actionを継承しない。
IoCパターンで作成する。
~~期待する入力~~注入するオブジェクトは、画面からの入力、セッション、システム日付、データベースへのアクセッサ、設定ファイル、ログ。
トランザクションは制御しない…が、たまに制御が必要なこともあった。
例外はキャッチしない。
Strutsのクラスは使わない。
業務処理実行メソッドの戻り値は出力用JavaBeanにしてしまう。
業務処理実行メソッドの戻り値で業務ロジックオブジェクトも返せるようにしておくと、業務ロジック→業務ロジックの連携が出来る。
業務ロジックを２層にする必要はない。
Actionを継承するクラスを一つだけ作って、各業務ロジックを呼ばせるようにする。
- 呼び出す業務ロジック名はstruts-config.xmlにで定義する。
- セッションチェック、トークンのチェック、トークンの生成はこいつにやらせる。
- トランザクションの制御はこいつにやらせる。
- 例外の補足はこいつにやらせる。

URL(業務ロジック？)ごとに設定される値は、<set-property>タグでstruts-config.xmlに定義しておく。
セッションのチェック、トランザクショントークンの生成、トランザクショントークンのチェックはstruts-config.xmlに定義しておく。
struts-config.xmlとvalidation.xmlは業務ごとに分割する(別にsubapplicationとか使わないくても、ただ分割するだけでいい)