SAStruts
Strutsのラッパーフレームワークで、Strutsをベースにしているが利用者はStrutsを意識して開発する必要がない。
（MVCフレームワークをより単純化したフレームワーク）
Java版のRuby On Rails
SAStrutsはStrutsをベースにしているが、利用する分にはあまりStrutsを意識する必要はない。
むしろまったく別のフレームワークと思ってもいい気がする。
（でもStrutsの知識があったほうが学習はより早い）
んで、結局SAStrutsを採用した。
理由は今回の開発は既に稼働しているシステムの完全な作り直しだったので、ある程度要件にブレがでないという前提で開発スピードを重視できると判断した。
設定より規約をさらに重視することで開発ストレスが少ない。
・Action（アクション内容を記述）
・entity（データベースに永続化するデータ。DTO的な）
・service（ビジネスロジックを記載）
に分けて配置することで、各クラスで読み込むと自動的にバインドしてくれる。
これだけで開発できるなら非常に便利で、実際ほとんどの開発はテンポよく開発できて非常によかった。
デメリットは
パッケージ配置でURLが決まる。
運用していくにあたりリファクタリングが発生し、パッケージ配置を分割したり再配置したりする場合にURLが変わってしまう。
そのためにURLのReWrite処理をいれるとかめんどい。
ユースケース毎のクラスで各実行メソッド毎にURLが決まるので、共通処理が書けない。
ログインチェック処理とか。（未ログインだったらどこかのページにリダイレクトするとか）
ここらへんは拡張に乏しい。
なんかいいアイデアはないだろうか
個人的にS2Strutsとかはゼロからの開発で利用したことがないので、どっちがいいとはわからないがパッケージでURLが決まってしまうことに支障がないのであれば断然SAStrutsがいいと思う。
S2StrutsでできることはSAStrutsでもできるし、S2Strutsでは設定しないとできなかったことがSAStrutsでは無設定でできるになっている。
（S2StrutsではActionやActionFormなどを自動的に認識させるためには設定を追加しなければならないが、SAStrutsだと自動的に認識される）
O/RマッパーはS2JDBCが推奨されているようだが、私はIBatisを採用した。
IBatis にはiBATORというツールが提供されているが、これが非常に便利だからだ。
事前に設計したデータベースのテーブルを作成しておくと、そのデータベースに接続してDao、Entitiy、SqlMapを自動生成してくれる。
私の場合は
DBDesignerでER図を書く
↓
DBDesignerのエクスポート機能でテーブル生成SQLを出力
↓
ローカルにテーブルを作成
↓
iBATORでDao、Entitiy、SqlMapを自動生成。
↓
要件に変更があればこれを繰り返し
※ちなみにS2JDBCの流れるようなインターフェースはIBatis abotorのCriteriaクラスで同じことができます。
最後にHotDeployは一度使ったら病みつきです。
これだけのためにSeasarにしてもいいぐらい。（極端だけど）
でもSpringへの対応できたらさらに幅が広がっていいなー
