この 2 つがどのように相互作用し、その境界がどこにあるのかを理解するのに苦労しています。それらは重複していますか？それらの間に冗長性はありますか？
両方に関連付けられた注釈があることは知っていますが、両方の簡単な説明を含む完全なリストを見つけることができませんでした。これが、それらの違いや重複する場所を明確にするのに役立つかどうかはわかりません.
本当に混乱するだけです。私は、EJB をかなりよく理解していると思いますが、CDI がテーブルにもたらすものと、CDI が EJB が既に提供しているものにどのように取って代わるか、または強化するかを正確に理解するのに苦労していると思います。
Java EE には複数のコンポーネント モデルが存在するため、現時点では少し混乱しています。それらは、CDI、EJB3、およびJSF マネージド Beanです。
CDIはブロックの新しい子供です。CDI Bean 機能dependency injection、scopingおよびevent bus. CDI Bean は、インジェクションとスコーピングに関して最も柔軟です。イベント バスは非常に軽量で、最も単純な Web アプリケーションにも適しています。これに加えて、CDI は と呼ばれる非常に高度な機能も公開していますportable extensions。これは、すべての実装 (Glassfish、JBoss AS、Websphere など) で利用できる追加機能をベンダーが Java EE に提供するための一種のプラグイン メカニズムです。 .
EJB3 Bean は、古いレガシー EJB2 コンポーネント モデル*から改良されたものであり、Java EE でアノテーションを介してマネージド Bean になった最初の Bean です。EJB3 Bean機能、、、、、、および。dependency injection_ declarative transactions_ declarative securitypoolingconcurrency controlasynchronous executionremoting
EJB3 Bean での依存性注入は、CDI Bean ほど柔軟ではなく、EJB3 Bean にはスコープの概念がありません。ただし、EJB3 Bean はトランザクションに対応し、デフォルトでプールされます**。これは、CDI が EJB3 のドメインに残すことを選択した 2 つの非常に有用なものです。上記の他の項目も CDI では利用できません。EJB3 には独自のイベント バスはありませんが、メッセージをリッスンするための特別なタイプの Bean があります。メッセージ駆動型 Bean。これは、Java Messaging System から、または JCA リソース アダプタを持つ他のシステムからメッセージを受信するために使用できます。単純なイベントに本格的なメッセージングを使用することは、CDI イベント バスよりもはるかに重量が大きく、EJB3 はプロデューサー API ではなく、リスナーのみを定義します。
JSF Managed Beansは、JSF が含まれて以来ずっと Java EE に存在していました。彼らも特徴dependency injectionとscoping. JSF マネージド Bean では、宣言型スコープの概念が導入されました。当初、スコープはかなり制限されていました。Java EE の同じバージョンでは、すでにアノテーションを介して EJB3 Bean を宣言できましたが、JSF マネージド Bean は XML で宣言する必要がありました。JSF マネージド Bean の現在のバージョンも最終的にアノテーションを介して宣言され、ビュー スコープとカスタム スコープを作成する機能によってスコープが拡張されます。同じページへのリクエスト間のデータを記憶するビュー スコープは、JSF Managed Bean のユニークな機能です。
ビュー スコープを除けば、Java EE 6 での JSF マネージド Bean の機能はまだほとんどありません。CDI にビュー スコープがないのは残念です。それがなければ、CDI は JSF マネージド Bean が提供するものの完全なスーパー セットになっていたからです。更新: Java EE 7/JSF 2.2 では、CDI 互換の @ViewScopedが追加され、CDI はまさに完璧なスーパー セットになっています。更新 2 : JSF2.3 では、JSF マネージド Bean は廃止され、CDI マネージド Bean が推奨されました。
EJB3 と CDI では、状況はそれほど明確ではありません。EJB3 コンポーネント モデルと API は、CDI が提供しない多くのサービスを提供するため、通常、EJB3 を CDI で置き換えることはできません。一方、CDI は EJB3 と組み合わせて使用できます (EJB にスコープ サポートを追加するなど)。
専門家グループのメンバーであり、CanDI と呼ばれる CDI 実装の実装者である Reza Rahman は、EJB3 コンポーネント モデルに関連付けられたサービスを一連の CDI 注釈として後付けできることを頻繁にほのめかしています。その場合、Java EE のすべてのマネージド Bean が CDI Bean になる可能性があります。これは、EJB3 が消滅または廃止されることを意味するのではなく、@Stateless や @EJB などの EJB 独自のアノテーションではなく、CDI を介してその機能が公開されることを意味します。
アップデート
TomEE と OpenEJB で有名な David Blevins が、CDI と EJB の相違点と類似点を彼のブログで非常によく説明しています: CDI, when to break out the EJB
* バージョン番号の増分に過ぎませんが、EJB3 Bean はほとんどの場合、まったく異なる種類の Bean でした。単純な単一のアノテーションを適用することで「マネージド Bean」になる単純な pojo に対して、EJB2 のモデルでは重量があり、非常に冗長な XML デプロイメント記述子がすべての Bean に必要であり、さらに Bean はさまざまな非常に重量があり、ほとんどの場合意味のないコンポーネント インターフェイスを実装する必要がありました。
** 通常、ステートレス セッション Bean はプールされますが、通常はステートフル セッション Bean はプールされません (ただし、プールされる可能性はあります)。したがって、両方のタイプのプーリングはオプションであり、EJB 仕様はいずれの方法でもそれを義務付けていません。
CDI:依存性注入に関するものです。これは、インターフェースの実装をどこにでも注入できることを意味します。このオブジェクトは何でもかまいません。EJB に関連していなくてもかまいません。これは、CDI を使用してランダム ジェネレーターを注入する方法の例です。EJBについては何もありません。EJB 以外のサービス、さまざまな実装またはアルゴリズムを注入する場合は、CDI を使用します (したがって、EJB はまったく必要ありません)。
EJB:理解できますが、おそらくアノテーションに混乱していると思います@EJB。これにより、実装をサービスなどに注入できます。主な考え方は、注入するクラスは EJB コンテナーで管理する必要があるということです。CDI は EJB とは何かを理解しているようです。そのため、Java EE 6 準拠のサーバーでは、サーブレットで両方を記述できます。
@EJB EJBService ejbService;
と
@Inject EJBService ejbService;
これが混乱を招く可能性がありますが、EJB と CDI の間の橋渡しをするのはおそらくこれだけです。
CDI について話している場合、他のオブジェクトを CDI 管理クラスに挿入できます (それらは、CDI 対応フレームワークによって作成される必要があります)。
他に CDI が提供するもの... たとえば、Struts 2 を MVC フレームワーク (単なる例) として使用し、EJB 3.1 を使用してもここで制限されます@EJB。Struts アクションで注釈を使用することはできず、コンテナーによって管理されません。しかし、Struts2-CDI プラグインを追加する@Injectと、同じことに対するアノテーションをそこに書き込むことができます (そのため、JNDI ルックアップはもう必要ありません)。このようにして EJB の能力が強化されますが、前述したように、CDI で注入するものは、EJB に関連するものであるかどうかに関係なく、それがその能力です。
PS。例への更新されたリンク