Discover millions of ebooks, audiobooks, and so much more with a free trial

Only $11.99/month after trial. Cancel anytime.

CDI - Dependency Injection in Java EE 7: Dependency Injection in Java EE 7
CDI - Dependency Injection in Java EE 7: Dependency Injection in Java EE 7
CDI - Dependency Injection in Java EE 7: Dependency Injection in Java EE 7
Ebook84 pages51 minutes

CDI - Dependency Injection in Java EE 7: Dependency Injection in Java EE 7

Rating: 0 out of 5 stars

()

Read preview

About this ebook

Seit Java EE 6 steht mit der Contexts and Dependency Injection (CDI) eine neue Technologie bereit, die dem Java-Enterprise-Entwickler seine Arbeit erleichtert. Mit der Version 7 erlangte die Plattform einige neue Features. Der Arbeitsbereich von CDI ist die Bereitstellung und Verknüpfung von Komponenten und Diensten als Basis für Enterprise-Applikationen.Der shortcut bringt dem Leser die wichtigsten Konzepte von CDI näher.Themen sind unter anderem die Bereitstellung und Injektion von CDI Beans, die Nutzung der Java-EE-Umgebung, die verschiedenen Injektionsmöglichkeiten sowie die Integration anderer Bestandteile von Java EE 7 [wie z. B. Enterprise JavaBeans (EJB) oder Java Server Faces (JSF)]. Dieser shortcut ist eine aktualisierte Neuauflage des shortcuts CDI - Dependency Injection in Java EE 6.
LanguageDeutsch
Release dateNov 20, 2013
ISBN9783868024937
CDI - Dependency Injection in Java EE 7: Dependency Injection in Java EE 7

Read more from Dirk Weil

Related to CDI - Dependency Injection in Java EE 7

Titles in the series (100)

View More

Related ebooks

Programming For You

View More

Related articles

Reviews for CDI - Dependency Injection in Java EE 7

Rating: 0 out of 5 stars
0 ratings

0 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    CDI - Dependency Injection in Java EE 7 - Dirk Weil

    http://www.caucho.com/resin/candi/

    2 Wozu braucht man das?

    Professionelle Anwendungen sind nicht monolithisch aufgebaut, sondern bestehen aus Komponenten. Zum einen ergeben sich bei der Entwicklung von Software aus der Analyse der Aufgabenstellung fachliche Bereiche, die durch fachliche Komponenten abgebildet werden können. Innerhalb dieser Komponenten lassen sich wieder Teile abgrenzen, diesmal eher technischer Natur. Die Komponenten benutzen andere Komponenten und die Plattformdienste, sind aber weitgehend abgegrenzt (Abb. 2.1).

    Abbildung 2.1: Anwendungskomponenten

    Eine Aufgabe der Softwareentwicklung ist es nun, diese Komponenten untereinander zu verknüpfen, sodass eine saubere Anwendungsarchitektur entsteht. Das kann natürlich mit einfachen Sprachmitteln von Java geschehen. Eine Komponente kann in ihrem Programmcode andere Komponenten instanziieren, indem sie new benutzt. Dadurch wird die Kopplung der Komponenten aber sehr stark, denn die aufrufende Komponente muss die benutzte sehr genau kennen, Änderungen sind aufwändig, der Einsatz einer alternativen Komponente unmöglich.

    Zudem profitieren solche Objekte kaum von der Umgebung der Anwendung: Der Applikationsserver „kennt sie nicht, kann also bspw. kein Monitoring und keine Laufzeitsteuerung dafür durchführen. Flexibler ist es, die benötigten Objekte vom Application Server herstellen zu lassen. In den früheren Versionen der Java EE – damals noch J2EE – hat man dazu weitgehend String-basierte Referenzen benutzt, hat also bspw. die benötigte Komponente per Namen im JNDI-Dienst adressiert. Hier stellt sich aber das Problem der „Zielgenauigkeit: Ist ein Objekt unter dem verwendeten Namen überhaupt vorhanden und hat es den richtigen Typ (Listing 2.1)?

    // Unsicher: Ist ein Objekt mit dem Namen konfiguriert?

    //          Falls ja, hat es den korrekten Typ?

    MyService myService

      = (MyService) jndiContext.lookup(ejb/myService);

    Listing 2.1: Referenzierung einer Komponente über ihren Namen

    Ein weiteres Problem ist die Abhängigkeit der aufrufenden Komponente von ihrer Umgebung: Der Code im Beispiel setzt unumstößlich voraus, dass es einen JNDI-Dienst gibt. Ein Test des Codes außerhalb des Applikationsservers ist damit unmöglich. Hier setzt die Idee Inversion of Control an, die den aktiven Teil der Komponentenverknüpfung aus der Komponente herauslöst und in die Laufzeitumgebung – den Container – verlagert: Nicht die Komponente besorgt sich die von ihr benötigten Serviceobjekte, sondern der Container liefert sie an. Dieses Verfahren firmiert unter dem Namen Dependency Injection – Injektion von benötigten Objekten, womit wir auch schon die beiden letzten Drittel des Namens CDI erklärt hätten (Abb. 2.2).

    Abbildung 2.2: Dependency

    Enjoying the preview?
    Page 1 of 1