it-swarm.com.de

Wie vergleichen sich CDI und EJB? interagieren?

Es fällt mir schwer zu verstehen, wie die beiden interagieren und wo die Grenze zwischen ihnen liegt. Überlappen sie sich? Gibt es Entlassungen zwischen ihnen?

Ich weiß, dass es Anmerkungen zu beiden gibt, aber ich konnte für beide keine vollständige Liste mit kurzen Beschreibungen finden. Ich bin mir nicht sicher, ob dies helfen würde, ihre Unterschiede oder Überlappungen zu klären.

Wirklich nur verwirrt. Ich (glaube ich) verstehe EJB ziemlich gut. Ich glaube, es fällt mir schwer, genau zu verstehen, was CDI auf den Tisch bringt und wie es das, was EJB bereits bietet, ersetzt oder verbessert.

103
Tim

CDI - es geht um Abhängigkeitsinjektion. Dies bedeutet, dass Sie die Schnittstellenimplementierung an beliebiger Stelle implementieren können. Dieses Objekt kann alles sein, es kann nicht mit EJB zusammenhängen. Hier ist ein Beispiel für das Injizieren eines Zufallsgenerators mit CDI. Es gibt nichts über EJB. Sie werden CDI verwenden, wenn Sie Nicht-EJB-Services, verschiedene Implementierungen oder Algorithmen einspeisen möchten (sodass Sie dort überhaupt kein EJB benötigen).
EJB, das Sie verstehen, und wahrscheinlich sind Sie durch die @ EJB-Anmerkung verwirrt - Sie können die Implementierung in Ihren Service oder was auch immer einbauen. Die Hauptidee ist, dass die Klasse, in die Sie injizieren, vom EJB-Container verwaltet werden soll. Scheint, dass CDI versteht, was EJB ist, also können Sie in Ihrem Servlet auf einem mit Java EE 6 kompatiblen Server beide schreiben

@EJB EJBService ejbService;

und

@Inject EJBService ejbService;

das kann Sie verwirren, aber das ist wahrscheinlich das einzige, was die Brücke zwischen EJB und CDI schlägt.

Wenn es sich um CDI handelt, können Sie andere Objekte in von CDI verwaltete Klassen einfügen (sie sollten nur von CDI-fähigen Frameworks erstellt werden).

Was CDI sonst noch bietet ... Zum Beispiel verwenden Sie Struts 2 als MVC-Framework (nur ein Beispiel), und Sie sind hier eingeschränkt, auch wenn Sie EJB 3.1 verwenden - Sie können @EJB-Annotation nicht in Struts-Aktionen verwenden, es wird nicht von verwaltet Container. Wenn Sie jedoch das Struts2-CDI-Plugin hinzufügen, können Sie dort eine @Inject-Annotation für dasselbe Element schreiben (daher ist keine weitere JNDI-Suche erforderlich). Auf diese Weise wird die EJB-Leistung erhöht. Aber wie ich schon sagte, was Sie mit CDI injizieren - es spielt keine Rolle, ob es mit EJB zusammenhängt oder nicht, und das ist seine Stärke

PS. aktualisierter Link zum Beispiel

48
Maxym

Es ist derzeit in der Tat ein bisschen verwirrend, da es jetzt mehrere Komponentenmodelle in Java EE. Sie sind [~ # ~] cdi [~ # ~] gibt. EJB3 und JSF Managed Beans.

[~ # ~] cdi [~ # ~] ist das neue Kind im Block. CDI-Beans verfügen über dependency injection, scoping und ein event bus. CDI-Bohnen sind in Bezug auf Injektion und Scoping am flexibelsten. Der Eventbus ist sehr leicht und auch für einfachste Webanwendungen sehr gut geeignet. Darüber hinaus stellt CDI eine sehr fortschrittliche Funktion namens portable extensions, eine Art Plug-in-Mechanismus für Anbieter, der Java EE) zusätzliche Funktionen bietet, die für alle Implementierungen (Glassfish, JBoss AS, Websphere usw.) verfügbar sind.

EJB3 Beans wurden aus dem alten EJB2-Komponentenmodell nachgerüstet* und waren die ersten Beans in Java EE, die über eine Annotation verwaltet wurden. EJB3-Beans verfügen über dependency injection, declarative transactions, declarative security, pooling, concurrency control, asynchronous execution und remoting.

Die Abhängigkeitsinjektion in EJB3-Beans ist nicht so flexibel wie in CDI-Beans, und EJB3-Beans kennen kein Konzept für das Scoping. EJB3-Beans sind jedoch transaktionell und werden standardmäßig gepoolt**, zwei sehr nützliche Dinge, die CDI in der Domäne von EJB3 belassen hat. Die anderen genannten Artikel sind ebenfalls nicht in CDI verfügbar. EJB3 hat zwar keinen eigenen Event-Bus, verfügt jedoch über eine spezielle Art von Bean zum Abhören von Nachrichten. die nachrichtengesteuerte Bohne. Dies kann zum Empfangen von Nachrichten vom Java Messaging System oder von jedem anderen System mit einem JCA-Ressourcenadapter verwendet werden. Die Verwendung von vollständigem Messaging für einfache Ereignisse ist weitaus schwerer als der CDI-Ereignisbus und EJB3 definiert nur einen Listener, keine Producer-API.

JSF Managed Beans gab es in Java EE seit der Aufnahme von JSF. Auch diese enthalten dependency injection und scoping. JSF Managed Beans führte das Konzept des deklarativen Scoping ein. Ursprünglich waren die Gültigkeitsbereiche eher begrenzt und in derselben Version von Java EE, in der EJB3-Beans bereits über Annotationen deklariert werden konnten, mussten JSF Managed Beans noch in XML deklariert werden. Die aktuelle Version von JSF Managed Beans werden schließlich auch über eine Annotation deklariert und die Bereiche werden um einen Ansichtsbereich und die Möglichkeit erweitert, benutzerdefinierte Bereiche zu erstellen. Der Ansichtsbereich, der Daten zwischen Anforderungen an die Seite same speichert, ist einzigartig Funktion von JSF Managed Beans.

Abgesehen vom View-Bereich ist für JSF Managed Beans in Java EE 6 nur noch sehr wenig verfügbar. Der fehlende View-Bereich in CDI ist bedauerlich, da CDI ansonsten ein perfektes Super-Set gewesen wäre des Angebots von JSF Managed Beans. Update: In Java EE 7/JSF 2.2 wurde ein CDI-kompatibles @ViewScoped hinzugefügt. CDI zu einem perfekten Super-Set machen. Update 2: In JSF2.3 wurden die von JSF verwalteten Beans zugunsten von von CDI verwalteten Beans aufgegeben.

Mit EJB3 und CDI ist die Situation nicht so eindeutig. Das EJB3-Komponentenmodell und die API bieten viele Dienste, die CDI nicht bietet, sodass EJB3 normalerweise nicht durch CDI ersetzt werden kann. Andererseits kann CDI in Kombination mit EJB3 - z.B. Hinzufügen von Bereichsunterstützung zu EJBs.

Reza Rahman, Mitglied der Expertengruppe und Implementierer einer CDI-Implementierung mit dem Namen CanDI, hat häufig darauf hingewiesen, dass die mit dem EJB3-Komponentenmodell verbundenen Dienste als Satz von CDI-Anmerkungen nachgerüstet werden können. In diesem Fall könnten alle verwalteten Beans in Java EE zu CDI-Beans werden. Dies bedeutet nicht, dass EJB3 verschwindet oder veraltet ist, sondern nur, dass seine Funktionalität über CDI statt über verfügbar gemacht wird EJBs eigene Annotationen wie @Stateless und @EJB.

Update

David Blevins von TomEE und OpenEJB erklärt die Unterschiede und Gemeinsamkeiten zwischen CDI und EJB sehr gut in seinem Blog: CDI, wann man die EJBs aufschlüsselt

* Obwohl es sich nur um eine Erhöhung der Versionsnummer handelt, waren EJB3-Beans größtenteils eine völlig andere Art von Bean: Ein einfaches Pojo, das durch Anwenden einer einfachen einzelnen Annotation zu einer "verwalteten Bean" wird, im Vergleich zu dem Modell in EJB2, bei dem ein Schwergewicht und Für jedes Bean war ein überaus ausführlicher XML-Implementierungsdeskriptor erforderlich. Außerdem musste das Bean verschiedene extrem schwergewichtige und größtenteils bedeutungslose Komponentenschnittstellen implementieren.

** Zustandslose Sitzungs-Beans werden normalerweise gepoolt, zustandsbehaftete Sitzungs-Beans normalerweise nicht (können es aber sein). Für beide Typen ist das Pooling daher optional, und die EJB-Spezifikation schreibt dies in keiner Weise vor.

186
Arjan Tijms

Albert Einstein: If you can't explain it simply, you don't understand it well enough

Ejbs und CDI sind ziemlich einfach zu verstehen.

Ejbs:

  1. Wird immer durch Bereichsqualifizierer mit Anmerkungen versehen, z. B. @Stateless, @Stateful, @Request usw
  2. Die Instanzen von Ejbs werden vom Java= EE-Framework gesteuert und gepoolt. Es ist die Pflicht des EE-Frameworks, die Instanzen für den Verbraucher bereitzustellen.

@Stateless

 public class CarMaker(){
    public void createCar(Specification specs){
        Car car = new Car(specs);
    }
}

Der CarMaker ist mit einem bestimmten Ejbs-Bereich versehen, daher ist es Ejb

CDI:

  1. Nicht vollständig vom EE-Framework verwaltet, müssen Instanzen von Ihnen erstellt werden.
  2. Es ist immer abhängig. Lassen Sie mich "Abhängig" anhand eines Beispiels erklären:

    class Specification { private String color; private String model; //- Getter and Setter }

Die Klasse Specification ist CDI, da sie nicht mit Ejb-Gültigkeitsbereichen beschriftet ist und auch dies durch Ihren Code und nicht durch das EE-Framework initialisiert werden muss. Ein Punkt, der hier erwähnt werden muss, ist, dass die Klasse Specification nicht mit Annotated versehen wurde und standardmäßig mit Annotated by @Dependent Anmerkung.

@Dependent  <- By default added 
class Specification { ... }

Further reading: Sie müssen mehr zwischen der Annotation des Ejbs-Bereichs und der Annotation des CDI-Bereichs lernen, um das Konzept weiter zu verdeutlichen

0
HA S