POJOは依存性注入を中断する

使用されるDIフレームワークとは無関係に、オブジェクトチェーン内の単一のPOJOは常にDIメカニズムを解除します。POJOは依存性注入を中断する

擬似コードの例：クラスBにおけるnew C()は、管理オブジェクトのチェーンを壊すよう

class A { 
    @Inject 
    private B b; 
} 

class B { 
    private C c=new C(); 

} 

class C { 
    @Inject 
    private D d; 
}

クラスC内注射は、動作しません。

私たちは現在、マニュアルオブジェクトの作成をDIメカニズムで段階的に置き換えることによって、古い（非DI）プロジェクトを改善しようとしています。

CをDIに移行するには、AとBを気にする必要はありません。あなたが注入したくない場合は、通常

2016-07-18 gorootde

あなたは既にDIを達成するために何かをしていますか？何してるの？ – aksappy

なぜ私はプライベートCを作成できないのですか？「新しい」DIインジェクションを使用してインスタンスを作成すると、もはや機能しなくなる – kuhajeyan

@kuhajeyanもちろんそれはありません。しかし、私の質問は、（Cで始まる）段階的に移行する戦略があるかどうかです。 – gorootde

（バイトコード操作なしで）コンストラクタへの直接呼び出しを保持することで、これを行うことはできません。

これは、必要に応じてコードを半自動的にリファクタリングする方法です。

通常のIDEでは、コンストラクタから/ refactoryファクトリメソッドを作成できます。その結果、new C()へのすべての呼び出しをリファクタリングすると、C.createInstance()（または、ファクトリメソッドが呼び出されたもの）に変換されます。

その後、依存関係注入フレームワークから実際にCを解決するためのファクトリメソッドを変更します。

2016-07-18 11:03:26

CあなたはC解決するには、コンテナを呼び出す：

C c = container.resolve(C.class);

をか、Cも、例えば注射されてみましょう

を使って、必要なオブジェクトを解決：

CDIためのいくつかのコード例である。ここ

@Inject 
private C c;

は、次のとおりです。コンストラクタを呼び出すときに

かは、前に行ったように

UpdateCustomerController controller = (Controller) BeanProvider.getContextualReference("updateController", false);

2016-07-18 10:48:05

しかし私の "古いコード"（私が触れたくない行）は 'new C（）'を使用します。 Cの作成に触れることなく、Cに注入する方法が必要です。 – gorootde

リファクタリングを部分的に進めたい場合は、 'C'をそのままにして、' C'クラスのコードを変更するだけです例。あなたが使用するよりも触れることなく。どのような依存性注射を使用していますか？ –

@k_wave 'C'の作成に触れたくない場合は、上記のコードを使用して、コンストラクタ内のコンテナから 'D 'を作成することができます。 –

答えて