CDIはSpringに代わるものですか？
Webアプリケーションをゼロから作成することを計画しており、Java EE 6標準に準拠するGlassfishの最新版を使用することが決定されたため、CDIを使用できるかどうかを分析しています。春の代わりに。
CDIはSpringの代わりになると言えますか？
CDIは「コンテキストおよび依存性注入」の略で、Springは依存性注入コンテナを取り巻く完全なエコシステムです。両方を比較するには、比較を区別する必要があります。
依存性注入は両方のコンテナで処理されます。主な違いは、CDIが動的（別名：ステートフル）の方法でDIを処理するという事実です。つまり、依存関係は実行時間で解決されます。 Springのアプローチはstaticです。これは、コンポーネントがcreation timeで接続されていることを意味します。一見一見するとCDI-wayは少し変わったように見えるかもしれませんが、はるかに優れており、より多くの高度なオプションを提供しています（2つの生産的なCDIアプリのバックグラウンドでこれを書いています）。
ecosystemを見ると、状況は異なります。Springにはa lot of jar（> 150）がバンドルされています。 CDI自体は非常に小さいです。典型的なCDIの使用法はJava EE 6アプリケーションサーバー内にありますが、サーブレットエンジンまたはJava SE。つまり、CDIを使用しても、Hibernate、JPA、EJBなどを使用することを想定していません。それはユーザー次第です。
より多くの機能が必要な場合、CDIにはポータブル拡張機能の概念があります（それだけでAPIに価値があります）。 Apache CODIやSeam 3のような独立した拡張モジュールが存在し、セキュリティ、メール、レポートなどのトピックをカバーしています。
要約すると、CDIはSpringエコシステムの「置換」にほかなりません。むしろ、Springの依存性注入メカニズムを改善したものです。これはJava EE 6の一部です。したがって、Java EE 6でGlasFishを使用している場合、CDIを必ず使用する必要があります。むしろ：SpringをJava EE 6に置き換えることはできますか？私の答えはかなり明白だと思います;-)
良いスタートを切るには、 溶接 をご覧ください...
Springは単なる依存関係注入コンテナーではありません。また、AOP用のツール、JPA、SQLなどで使用するテンプレートなどがあります。
ただし、CDIは、SpringのDI APIの代替として使用できます。
Apache OpenWebBeans をCDI実装として使用し、MyFaces CODIをいくつかのプロジェクトの移植可能な拡張機能として使用しています。私はそれにとても満足しており、問題はありませんでした。現在、OpenWebBeansにはドキュメントの観点から少し欠けていますが、何か機能が得られない場合は、MyFacesが提供するMavenアーキタイプを使用して、必要なすべての依存関係を持つ単純なプロジェクトを生成するか、メーリングリストで尋ねることが非常に簡単です。アプリケーションで作業するだけで、厄介なバグにブロックされないのは素晴らしいことです。また、Springで多くのプロジェクトを行いました。大丈夫ですが、次のプロジェクトで何を使うのかと尋ねると、明確な答えはOpenWebBeansとCODIです！ OpenWebBeansは非常に採用しやすいため、WeldよりもOpenWebBeansの方が好きです。これは、公式のCDI API/SPIでカバーされていないものを多かれ少なかれカスタマイズでき、runtimeperformanceが優れているためです。そして最初のプロジェクトの後、私はCODIが非常に安定しているので二度と質問しません。彼らは定期的なリリースを持ち、それらのほとんどは生産性を大きく改善する素晴らしい新機能をもたらしました。 CODIは、最も安定した場所であり、ほとんどのイノベーションがCDIの土地全体から生まれた場所です。
あなたの質問に答えるために：私にとって、CDIはSpringを完全に置き換えましたが、そのギャップを埋めるポータブルな拡張機能が必要です。標準としてのCDIは、すべてを解決することを意図したものではなく、会話のような部分は設計上壊れています。良いニュースは、MyFaces CODIのような素晴らしいプロジェクトがあることです。 CODIは、これらの問題のほぼすべてを修正します。