私はたくさんのコンポーネント(JARとしてパッケージ化されています)を書いています。それらはすべてDI用にGuiceを使用しています。これらのコンポーネントは再利用可能なもので、他の川下のプロジェクトで使用される "コモン"タイプのJARです。Guice:ヘッドレスJARで注入/ブートストラップを開始するタイミングは?
私はGuicと具体的にはModule
を実装し、それを使ってオブジェクトを結合し、すべてのDIを構成することを理解しています。また、Guiceインジェクタが作成された後、モジュールが設定されているすべての依存関係がそのインジェクタからinjector.getInstance(SomeClass.class)
でフェッチされるような単一の「ブートストラップ」フェーズがあるはずです。
これは、エントリーポイントを持っていて、init()
スタイルのメソッドを呼び出してGuiceをブートストラップすることができますが、エントリーポイントのないヘッドレスJARでは、試してみると苦労していますGuiceをブートストラップする時期/場所/方法を決定します。
これはクラスパス上に存在するJARです。任意の時点で、外部エンティティが呼び出すことができ、内部のクラスとメソッドを呼び出すことができます。メソッドが依存関係がまだ設定されているかどうかを確認するためのチェックを行い、そうであればブートストラップメソッドを起動する、「遅延初期化」のセットアップを使用することを考えました。
しかし、それは本当にひどい解決策です!部分的には、すべてのクラスに独自のModule
(これはばかげている)が必要なので、DIベースのコードで自分のコードベース全体を汚染することもあります。
ここでGuiceの基本的な部分がはっきりしていません。そうでなければ、Guiceは、開始から終了までの実行がわかっていて制御されているアプリ以外の方法では使用できません。どのコードサンプルも巨大なプラスです!前もって感謝します。
+1 Guiceのプライベートモジュールはかなり完全に壊れていますが(guice-multibinderやguice-servletなどを使用すると、既知のバグのためプライベートモジュールがまったく動作しません) –
興味深い哲学と私1つのハングアップのためにそれを採用することに全く反対しません。ライブラリに「A」と「B」の2つのコンポーネントがあり、「B」が「A」に依存するシナリオを想像してみてください。現在は下流のプロジェクトで両方を使用しています。私のアプローチでは、 'A'と' B'は自分自身を構成するので、両方を使うこの第3のコンポーネント( 'C')は設定について心配しません。あなたのアプローチでは、 'C'はiself **と' B'のために 'A'を設定する必要があります。たとえば、「A」には、ログ・コンポーネントがあり、ログ・コンポーネントがどこから来ているかを指定できます.2つのログ構成が必要です。 – IAmYourFaja
@AdamTannon:AとBには自分自身で構成するのに十分な情報がないと、あなたのアプローチは崩れます。私のアプローチでは、CはAを一度構成し、それ自身とBの*同じ*バインディングを使用するか、または異なるものを使用することができます。 –