DIコンテナにおける依存性の記述や解決には
これまで大きく二つのスタンスがあったかと
思います。
一つはSeasarのように自動バインディング
を駆使して設定ファイルを簡略化するもの、
もう一つはSpringのように設定ファイルに
明示的かつ詳細に記述するものです。
Guiceが登場したことで、AnnotationをJava
コードで全てをカバーし、XML設定ファイル
を使わないというスタンスが加わりました。
(Seasarでは以前から命名規則による指定が
ありますし、SpringについてもSpring Java
Configrationが出てきているので、一概に
は括れませんが)
確かにコード本体にはインジェクションの
指定のみ記述し、詳細はModuleに記述する
というスタイルには様々なメリットがあります。
まずはModuleにコンパイルチェックが入る点です。
XML設定ファイルの記述が間違っていて、実行時に
判明するというミスは案外起きやすい気がします。
Annotationについても「@Singleton」のように
コードを見て、コンポーネントのライフサイクル
を掴めることは第三者がコードを見る時のことを
考えると利便性に適っています。
個人的には「@ImplementedBy(***.class)」で
デフォルトのバインディングを指定できる点が
気に入っています。コード単体でモック試験を
したい場合にモックとして使われるクラス名が
一目で確認できるからです。
また、任意のメソッドにWeavingしたい場合の
方法が最初は良くわからなかったのですが、
Moduleの中で
と記述し、「Transactional」をAnnotationとして
bindInterceptor(
only(Order.class),
annotatedWith(Transactional.class),
new TXInterceptor());
定義しておけば、コード中に「@Transactional」
を付加したOrderクラスのメソッドに注入されます。
もちろんインターセプタとしてはAOP Allianceの
MethodInterceptorを実装した一般的なものを指定
することができます。
「only(...)」の部分を「Order.class.getPackage()」
とすればOrderクラスが属するパッケージ全体を対象
にできるといったように対象クラス指定も柔軟です。
Spring Java Configurationの動きなども見ると、
やはり今後はXML設定ファイルはなるたけ使わずに
Javaコード内で完結できるようにする方向が主流
になっていくのでしょうか。
引き続き、DIの使い勝手の進化を
ウォッチしていきたいと思います。
