Spring などDIコンテナの利点とは？

質問

ちょっと基本的な話ですみません。
雑誌で読んだだけでは良くわからなくて・・。

Spring などDIコンテナの利点とはどういった点が
あるのでしょうか？。

EJB2.0に取って変わるもの・・それだけでは
ないように感じます。

「デザインパターン」など既存の手法などは必要なくなる
のでしょうか？。

DI技術を取り入れることで工数などは劇的に
変わるのでしょうか・・。

回答No.1

noname#49664 · ベストアンサー

Springはそれほど本格的に使ったわけではないんですが・・・。
　DIでは、POJO（Plain Old Java Object）を利用しますから、やたらと重たいEJBより動作は軽快ですね。また、単なるサーブレットコンテナ（内のDIコンテナ）で動くので、EJBコンテナを必要とするEJBよりサーバも軽快です。
　それから、DIではオブジェクトへの値設定などはすべてソースコードから切り離されますから、それらの修正のためにクラスをリコンパイルする必要がありません。その点、ちょっとした修正のためだけにプロジェクトをリビルドしデプロイするEJBより開発も軽快でしょう。
　工程数そのものにどれぐらい影響があるかはちょっとわからないのですが、そうした「すべてにおいてフットワークが軽くなる」という利点はあります。

　ただ、DIの最大のメリットは、開発そのものより、その後のメンテナンスだと思います。プログラムってのは作って終わりではなくて、その後に何度も何度も修正します。基本が出来上がると、それを継ぎはぎして使い続けるわけです。DIではクラス間の結びつきが粗ですので、途中で一部を置き換えたりするのも簡単ですし、設定の変更程度ならコードを一行も書き換える必要はありません。
　システムのライフサイクルを考えるとき、DIを導入した方が後々の改修などでは大幅に手間が少なくすみ、システム自体も長生きできるように思えます。

デザインパターンなどは必要なくなるのか？というと、これは全く別の話でしょう。DIでもデザインパターンは使われます。DIは「いかにしてクラスから依存性を切り離すか」の問題解決技法であり、システム全体のデザインなどに関わるものではないように思えます。現に、SpringもMVCにそって設計されていますし、Strutsなどと併用することも考えられています。
　もちろん、DIを導入することで変わる部分はありますけど、デザインパターンの考え方自体はそのままいきていますから、不要となるわけではないと思います。

ちなみに、EJB 2.0に取って代わるということがいわれましたが、EJB 3.0では逆にDIを取り込んでますので、今後は「DIによるライトウェイトなEJB」という不可思議なものが生まれそうです（笑）。ですので、EJBがなくなることはないかと思います。

以上、まぁ個人的な意見ということでご参考程度に。