CDIは状態管理をするDI

CDIは状態管理をするDI

CDI仕様は単なるDIの仕様ではありませんし、Java EEに新しいAPIが追加されただけということでもありません。筆者は今後のJava EE仕様やJava EEアプリケーション開発の手法に大きな影響を与える潜在的な力を秘めていると考えています。CDIは「エンタープライズアプリケーションには状態がある」ということを前提にDIが設計されています。このことを説明するため、CDIと普通のDIとの違いを説明します。

まず、第一に、ライフサイクル管理によってアプリケーション開発者がインスタンスを生成したり、削除したりというコーディングをする必要がなくなるということです。EJBのインスタンスの管理をコンテキストに任せればコードは非常に単純になります。EJBをコンテキストに関連づけられればそれをインジェクションで取得して、その解放処理はコンテキストに任せることができます。

次に、インジェクションはコンテキストの状況に応じて動的に行われるということです。インジェクションは、該当するインスタンスがコンテキスト上に無い場合に実行されるので、短いスコープのインスタンスは必要に応じて毎回別々のインスタンスが生成され、それがインジェクトされます。長いスコープの場合は、同じコンテキストであれば、同じインスタンスを利用し続けます。インスタンスの生成はコンテキストの状況に依存し、ユーザーはそれが「いつ」作られたかということを意識しません。

これらの特徴を別の言葉で言い換えると、CDIはDIを使ったWebアプリケーション開発に「スコープ」の概念を持ち込んだと言えるでしょう。Servlet仕様では従来、Request, Session, Applicationというスコープは存在しましたが、それらのメモリ領域にデータをセットするのは開発者の責任で、処理終了後に解放を忘れるとテスト時や本番運用時にセッションリークという形で表面化しました。CDIはこの状態管理を自動化します。

CDIはAPIをサービスに変える

CDIという状態管理型のDIによってアプリケーション開発が変わるとすれば、それは機能を使う側と使われる側の責任の分担です。CDIによって今までライブラリとして利用していたJava EE機能群を「サービス」として扱うことが可能になります。従来のJava EE開発は、本当に使いたい機能を呼び出すためのコード以外に、JNDIのアクセスのような前処理や、利用後のセッションのクローズなどの後処理をコーディングする必要がありました。

CDIを使ったアプリケーション開発では、開発者はサービスを利用するだけで、サービスをするための前処理や後処理は意識しません。そのような処理はサービスを提供する側の責任なのです。それゆえ、サービス利用者はそのサービスを実現するための実行途中の状態（=コンテキスト）の管理はまったく意識する必要がありません。サービス利用者にとってはサービスを利用することだけに集中できるので、アプリケーションコードがとてもすっきりします。

CDIによるO/Rマッピングの例

CDIによって従来は使うのが面倒だったAPIについても、もっと簡単に使えるようになります。例えば、JPA（Java Persistence API）やHibernateでのセッション管理を考えてみましょう。O/Rマッピングの機能を使うためにはプロバイダとの間でセッションを確立する必要があります。アプリケーション開発者はこのセッションを保持し、DBの処理を行い、セッションを解放します。一般的には、このような処理にDAO（Data Access Object）を定義することでしょう。

DIを使えば、このDAOをインジェクションで取り出して簡単に利用できます。CDIでは、さらに、サービスが状態を持つと言う点が異なります。DAOについては、従来のDIではRequestスコープしか存在しなかったのですが、CDIではアプリケーションがその境界を定めることができるConversationスコープを使います。Conversationを使うとDBアクセスによって得たデータをコンテキスト上にアプリケーションが必要とする間だけキャッシュすることが可能になり、そのコンテキストが終了すると解放することが可能になります。