DIコンテナを試してみた

今、流行ということで、DIコンテナを試してみました。
Seasar2は実際にサンプルをコーディングして動かし、Springは書籍のCD-ROMに入っていたサンプルアプリを動かして、ソースを眺めてみたみただけ。

Injectionには種類があるのか・・・とか、Asspectはこうやって動くのか・・・と分かっても、ボーッとしているだけでは、一体何が便利なのか分からない。

でも、実際にWebシステムとかの開発を思い浮かべてみると、なるほどと思う部分もある。

Asspectの便利さは分かりやすい。
例えばロギングとか、トランザクション管理といったアプリで共通的に使用される技術は、今まではフレームワークの機能として盛り込んで、それを各プログラマが使うことが多い。本当に共通的なロギングだと完全にフレームワークに組み込んで、プログラマは無視して良いようになる。しかし、ビジネスロジック依存のロギングやトランザクション管理はプログラマのコーディング次第だ。あぁ、EJB（CMP）を使えばトランザクション管理はコンテナ任せに出来るか。

こうした「共通的に使用される技術」を、最近はCrosscutting Concern（逆に業務要件はCore Concern）と呼ぶようだが、これを全体的にAsspectに任せられるようになる。プログラマのコーディングは不要で、定義ファイルで「宣言的」に使用できる。つまり、ビジネスロジックでの「この」メソッドを使う時は、事前か事後に特定のロジックを走らせることができ、そこでロギングやトランザクション管理をやらせるわけだ。宣言的に使用できるので、後付け可能なのは良い。で、そのビジネスロジックはPOJOであって、そういうAsspectを使用しなければ、普通に使える（例えばテストできる）のもメリット。

では、Injectionの方はどうか。
何かのオブジェクトを、コンストラクタやセッターメソッド等を経由して、DIコンテナが代入してくれるというのがInjection。簡単に考え付くのは何かのContextをlookupする時の代用だが、他にはないのか？
面白いと思ったのは、インスタンス管理機能だ。Seasar2の場合、管理の種類にrequestとsessionがある。これは使えそう。例えば、Webシステムであるオブジェクトをリクエストをまたいで使いたいとする。今までの作り方ならHttpSessionに格納しておいて、それを次のリクエストで取り出す・・・というようなロジックをビジネスロジックの一部として書く。Seasar2なら、sessionでインスタンス管理させれば、片付きそうだ。
JSFのManaged Beanでも同じことが出来る。しかし、プレゼンテーションより内部寄りのレイヤーを何とかしたい場合だったら、Seasar2でしか出来ないということになる。EJBでいうところの、Statefull Session Bean的なものだろうか。EJBを使わない場合、プレゼンテーションでないものまでHttpSessionに入れざるを得ないケースがあったが、それは回避できそうだ。

・・・。

Seasar2のドキュメントを見ると、Injectionは「コンポーネント同士がインターフェースのみで会話することにより依存関係をなくす」ことが実現し、メンテナンス性や再利用性の向上等のメリットがあるとのこと。
オブジェクト間の依存を何でもなくしてしまうのは無意味だと思うが、あくまで「コンポーネント間」なら依存関係はない方が良い。
やはり、Session Bean的なものを軽量に動かせるという理解で良いのだろうか。

この記事、あくまで「メモ」ですから。間違いまくりかもしれませんので、真に受けないようにしてください。（ちゃんと分かったら、また書きます）