はじめの一歩

S2Container
とりあえず基本の使い方はわかった。
OGNLで柔軟なことができるみたいだけど、できるだけ無茶な使い方はしないように気をつけないとわけのわからん構成になってしまいそう。Javaコードに書けばいいのになんでdiconファイルにかいてんの、みたいな。
調子に乗ってなんでもかんでもContainer経由にしちゃいそうなんで気をつけよう。直接newした方がよいものはたくさんあるので。

目安としては↓こんな感じだろうか。

  • JDK標準パッケージものは直接new
    • インタフェースが定義されていて、かつ、切り替える可能性がある実装が複数個ある場合はコンテナ経由でもいいけど、ListとかのCollection系で一々それをやる必要もないだろう。まとめると、どの実装を選ぶかで振る舞いが変わるような重要な局面でのみコンテナ経由ということで。
  • 独自実装するもの
    • レイヤ構成が分かれる部分などの依存関係→当然DIコンテナ利用
    • ユーティリティ、ヘルパ、ValueObject、例外系クラス→直接new
    • その他、まだよくわからないもの→直接new (必要と思ったときにDIコンテナに登録)

まだ実際使い込んでないので、ちらしの裏レベルだけど。

S2AOP
限定されたクラス、メソッドにアスペクトを適用するのはとても簡単にできそう。トランザクションとか。JavaWorld5月号の特集でSpringとの比較があったけど、実際、Springより断然簡単だ。
でも、独自実装した全クラスのpublicメソッドに対して一気にトレースログの出力処理を編みこみたい、という場合はどうするのだろうか?
ぱっとよんだ感じ、なさそうなんだけど…。
とりあえずAspectJとかならできそうな予感。
それとも、そのような処理はそもそも意味がないということか?
トレースログの処理は埋め込んでおいて、SUN標準Loggerやlog4Jの機能でログレベル制御をする、という方式で今までやってきたんだけどなぁ。

S2Unit
Seasar - DI Container with AOP - を見ると、今までJUnitで悩んでたほとんどすべてに対して何らかの回答が用意されているような感じ。
DB系テストのときのExcel連携って発想がすごい。Seasarがオリジナルなんだろうか?
でもテストクラスの隣にExcelファイルをおいたらやたらと数が多そうで整理しにくそう。Excelファイル専用にあえてサブパッケージを切った方がいいかな?
と思ったけど、同じディレクトリでファイルが並んでた方がアクセスしやすいか…。

S2JDBC
一年前くらいに、汎用DAOフレームワークを構想していたことがあったんだけど、全部ここで実現されてるじゃん。いや、むしろ機能、拡張性、完成度といいはるか上をいってる。
これは使える。けど、S2DAOの方が実は気になってる。早く試してみたい。