アプリケーションアーキテクチャ
たまには整理。
ずっと、くーす風のアーキテクチャで作ってきたけど、
整理すると、こんな感じで良いんじゃないかなーって思ってる。
- Action
- 画面と1:1
- Requestスコープ
- Form
- サブアプリケーションに1つ
- 入力画面のFormと1:1
- Sessionスコープ（実質的にはSubApplicationスコープ）
- Converter
- Formと1:1
- Singleton
- Service
- サブアプリケーションに1つ
- Singleton
- Dao
- テーブルと1:1
- Singleton
- Entity
- テーブルと1:1
- S2コンテナで管理しない
- Dto
- 好きに作ってくれい
- S2コンテナで管理しない
- トランザクション境界はService
という感じ。
もちろん、ActionもServiceもインタフェースは作らない。
AOPは命名規則で掛ける。
S2JSFのExampleだと、*DtoをS2コンテナに管理させてるけど、
それだと管理不要なDtoまで管理されちゃうので、
本当に管理が必要なものだけ（つまり入力に使うものだけ）
xxxFormという命名規則で管理する。
Pageクラスのように、画面と1:1のクラスを作ると
同じようなクラスがたくさんできるので、ちょっと勘弁。
（S2JSFではPageを作る恩恵があまりないし）
なのでFormはサブアプリケーションに一つ作る。
入力画面も確認画面もFormを使う。
値に対するラベルはFormにプロパティで持たせるか（EmployeeDtoのdnameと同じ）
「値:ラベルのMap」をSingletonで管理させておいて、HTML上でバインドさせる。
自分的には後者の方がオススメ。
登録／更新／削除のために、Serviceに値を渡す時は
ConverterでFormをDtoに変換してから渡す。
逆に更新のためにFormを作る時も、
ActionでConverterを使ってDtoからFormを作る or 値をコピーする。
検索結果は、DtoやDtoのListとして取得して、それをそのまま画面に出力する。
Entityに追加属性（関連するEntityとか、値に対するラベルとか）を
持たせても良いかも知れないんだけど、
一応、テーブル構造が変化した場合なんかに対応するために
GenerationGapパターンとして、EntityとDtoは分けておく。
