次期プロジェクトでの汎用化提案の一環としてSeasarを評価中

次のプロジェクトは基本設計として汎用化設計が重視されているので、前回そのお客さんのために開発したフレームワークの拡張と統合という観点で検討中。
前回開発したフレームワークの基本思想もDRY原則に則っている。（当時はDRY原則っていう言葉はなかったが。）
個人的にはSTRUTSみたいな、設定ファイルばりばりなものはあまりすかない。
前回作ったのは依存関係の整理もできてかつ同じような設定をいちいち書かなくていいものは書かないでいいようにできるWEBアプリの軽量フレームワーク。
依存関係があるべきところは、あるべきところにそれを書く、同じ意味にすればすむところは同じ意味で書くという設計思想にしたら、シンプルかつ必要十分という点でそのシステムの背丈にあったいいものができたように思う。
フレームワーク部の実装は２日ほどで完了した。
既存のフレームワークにもそれ自体をのせらるよう柔軟性のある設計にしたので、ほかのフレームワークにのせることも簡単にできる構造になっている。

アスペクト指向自体には改良の余地がある（というより現状では特に大規模業務アプリには向かないと思う）とつねづね思っているんだが、それでもSeasarにはDRY原則に則った考え方があるので気に入っている。
前回の機能でたりない、トランザクション制御とDBアクセスサポート機能（SeasarDao）をSeasarを使ってサポートしていけばとてもシンプルかつ強力なものになりそうな気配がある。
一方でSeasarにないのはバッチ関連のサポート。（追記：ジョブスケジューラはあるけど。）
バッチのフレームワークをDIコンテナ前提で開発しバッチの業務クラスをPOJOで実装の方式を検討する。
ジョブコントローラーとの連携と、WEB側との連携をどれだけ隠蔽化とパラメータ化できるかが汎用化設計の鍵になるだろう。