私は、2つの要素がどのように相互作用し、それらの境界がどこにあるかを理解するのに苦労しています。それらは重なりますか?それらの間に冗長性はありますか?
両方に関連付けられた注釈があることは知っていますが、簡単な説明で両方の完全なリストを見つけることができませんでした。これがどのように異なるのか、どこで重複するのかを明確にするのに役立つかどうかはわかりません。
本当に混乱しています。私は(と思う)EJBをかなりよく理解しています。CDIがテーブルにもたらすものと、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を使用しても制限されます-Strutsアクションで@EJBアノテーションを使用することはできません。容器。ただし、Struts2-CDIプラグインを追加すると、同じものに対して@Injectアノテーションを書き込むことができます(したがって、JNDIルックアップは不要です)。これにより、EJBの能力が向上します。しかし、前述したように、CDIで注入するもの-EJBに関連するかどうかは関係ありません。それがその力です
PS。例への更新されたリンク
現在、Java EE。に複数のコンポーネントモデルがあります。それらは[〜#〜] cdi [〜#〜]、EJB3およびJSF管理対象Bean 。
[〜#〜] cdi [〜#〜]はブロックの新しい子供です。 CDI Beanは、dependency injection
、scoping
、およびevent bus
を備えています。 CDI Beanは、インジェクションとスコープに関して最も柔軟です。イベントバスは非常に軽量で、最も単純なWebアプリケーションにも非常に適しています。これに加えて、CDIはportable extensions
と呼ばれる非常に高度な機能も公開しています。これは、ベンダーがJava EEすべての実装(Glassfish、JBoss AS、Websphereなど)で利用可能です。
EJB3Beanは、古いレガシーEJB2コンポーネントモデルから改造されました。* Java EEの最初のBeanであり、アノテーションを介してBeanを管理します。EJB3Beanはdependency injection
、declarative transactions
、declarative security
、pooling
、concurrency control
、asynchronous execution
、およびremoting
。
EJB3 Beanの依存性注入はCDI Beanほど柔軟ではなく、EJB3 Beanにはスコープの概念がありません。ただし、EJB3 Beanはトランザクション対応であり、デフォルトでプールされます**、CDIがEJB3のドメインに残すことにした2つの非常に有用なもの。他の言及されたアイテムは、CDIでは利用できません。 EJB3には独自のイベントバスはありませんが、メッセージをリッスンするための特別なタイプのBeanはあります。メッセージ駆動型Bean。これは、Java Messaging SystemまたはJCAリソースアダプターを備えた他のシステムからメッセージを受信するために使用できます。単純なイベントに本格的なメッセージングを使用することは、CDIイベントバスよりもはるかに重要です。 EJB3はリスナーのみを定義し、プロデューサーAPIは定義しません。
JSFマネージドBeanは、Java JSFが含まれてからずっとEEに存在していました。これらもdependency injection
とscoping
。JSFマネージドBeanは、宣言的スコープの概念を導入しました。元々、スコープはかなり制限され、同じバージョンのJava EEでEJB3 Beanが既にアノテーションを介して宣言できましたが、 JSFマネージドBeanは依然としてXMLで宣言する必要がありました。JSFマネージドBeanの現在のバージョンもアノテーションを介して最終的に宣言され、スコープはビュースコープとカスタムスコープを作成する機能で拡張されます。 sameページへのリクエストは、JSF Managed Beansのユニークな機能です。
ビューのスコープを別にすれば、JSF Managed BeanのJava EE 6.ではまだほとんど行われていません。 Update:In Java EE 7/JSF 2.2 a 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独自のアノテーション。
更新
TomEEとOpenEJBの名声のDavid Blevinsは、ブログでCDIとEJBの違いと類似点を非常によく説明しています。 CDI、いつEJBを分割するか
*単なるバージョン番号の増分ですが、EJB3 Beanはほとんどの場合、まったく異なる種類のBeanでした。単純な単一の注釈を適用することで「マネージドBean」となる単純なpojoです。非常に詳細なXMLデプロイメント記述子が、すべてのBeanに必要であり、さらに、Beanはさまざまな非常に重いコンポーネントインターフェースを無意味に実装するために必要でした。
**ステートレスセッションBeanは通常プールされ、ステートフルセッションBeanは通常プールされません(ただし、プールは可能です)。したがって、両方のタイプのプーリングはオプションであり、EJB仕様ではどちらの方法でも義務付けられていません。
アルバートアインシュタイン:If you can't explain it simply, you don't understand it well enough
EjbsとCDIの理解は非常に簡単です。
Ejbs:
@Stateless
public class CarMaker(){
public void createCar(Specification specs){
Car car = new Car(specs);
}
}
CarMakerには特定のEjbsスコープが注釈されているため、Ejb
CDI:
常に依存しています。例で「依存」を説明します。
class Specification { private String color; private String model; //- Getter and Setter }
Specification
クラスはCDIです。これは、Ejbスコープで注釈が付けられておらず、EEフレームワークではなくコードで初期化する必要があるためです。ここで注意すべき点の1つは、Specification
クラスに注釈を付けていないため、デフォルトで@Dependent
注釈による注釈が付けられていることです。
@Dependent <- By default added
class Specification { ... }
Further reading:
EjbsスコープアノテーションとCDIスコープアノテーションの間でさらに学習する必要があります。これにより、概念がさらに明確になります。