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

Von Dirk Weil

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.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 20. Nov. 2013
• ISBN: 9783868024937

Buchvorschau

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