DIコンテナ - しんさんの出張所はてなブログ編

DIネタにのっかってみる。

デメリットはあるセッターがあったときに、これがDIコンテナのためのものなのか、違うのかがわかりにくいことです。セッター全てがDIコンテナのためのものではないケースが多いと思うのでそのケースではある程度何のためなのかは補足的な情報があるほうが便利です。

おいらもここが気になっていて、だからこそアノテーションによる明示って重要だと思ってる。逆にセッターを見つけるとデフォで積極的にインジェクトしまくって、インジェクトしたくないときにマークをつけるのは個人的には非常にわかりにくいかなと。

インジェクトタイプとデフォルトのスコープを表にすると以下のようになるはず。

コンテナ	コンストラクタ	セッター	フィールド	メソッド	デフォルトスコープ
Spring	○	○	○	○	シングルトン
Guice	○	○	○	○	プロトタイプ
EJB3	-	○	○	-	なし（アノテーションがスコープを直接あらわす）
Seasar2	○	○	○	○	シングルトン

あーこれだけだと差がなくてつまらん。

むしろEJB3だけ貧弱に見えるし。デフォでリモートアクセス、セキュリティ、トランザクション、持続性、非同期など使える上に唯一設定ファイルや設定のためのコードが必要としていない環境だったりする。つまり環境構築が一番容易。

例えばデータソースをインジェクトしてトランザクション管理つけてJDBCアクセスするコードを書くとき一番シンプルになるのはEJB。他のコンテナはAOPによるトランザクション管理等が面倒だったりする。

Guiceのデフォルトスコープの考え方が個人的には気に入っている。Struts以降よくみるようになってしまった何でもかんでもシングルトンにしてこのメソッド内だけでやりくりしろやゴルァってのは好きじゃない。

いずれにせよデータベースのコネクションをはじめ、環境によって異なる設定はwarファイルに入らないように心がけたいところ。まぁデータベースさえつながってしまえばあとはデータベースの環境設定テーブル（ないシステムは見たことない）から引っ張ればよいからコネクション周りだけ注意すればよいのかな。