DIコンテナとかインタフェースとか

がんばって書いたのでこっちにも載せておこう。

EJBコンテナとDIコンテナは対立するものではないと思います。DIコンテナの役割はあくまでも「依存性の解決」で、たとえEJBを使うとしても「依存性の解決」の点でDIコンテナ使うのは有効だと思います。（AOPと組み合わせることでEJBを使う必要がなくなることもあると思いますが）

コンテナによる「依存性の解決」がない場合はコンポーネントをlookupしなければいけませんが、コレが面倒くさいというのがポイントじゃないでしょうか？さらにlookupして得たインスタンスをキャストする必要があったり、コンポーネント間の依存関係が連鎖する場合に依存性の解決を記述する必要があったりとコードは煩雑になりがちです。DIコンテナは設定ファイルを必要としますが、単にコンポーネントを登録するだけで済みますのでコードで依存性を解決するよりもはるかに記述量が少なくてすみます。（コンテナが依存関係を自動解決する機能を持つ場合を想定しています。）

DIコンテナの良いところは、インタフェースベースの設計/開発を簡単にすることだと思います。DIコンテナのおかげでクライアントはコンポーネントをlookupする必要がなくインタフェースを介してコンポーネントにアクセスできます。インタフェースのメリットには柔軟性、拡張性、プラグ可能性、実装と仕様の分離などがありますが、DIコンテナを使うとコードに複雑さを持ち込むことなくインタフェースのメリットが享受できます。

関係の切れた構成でデバッグしにくい、メンテナンス性が落ちる、再利用できる/できない、コンポーネントの粒度などと言った話題は、DIコンテナとは直接関係なくインタフェースを使った設計の問題だと思います。
私はDIコンテナの是非を問う議論はインタフェースの是非を問う議論につながっていると思います。
インタフェースベースの設計/開発に意義を見出す人はDIコンテナを便利だと感じ、インタフェースベースの設計/開発に抽象化による危険性を覚える人はDIコンテナは不要と感じるのではないでしょうか。