Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

Java EE 7 Grundkurs

Produzenten

Testen Sie unsere 2017 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Ein Programmierer erlangt mit Hilfe der Producer-Annotation zusätzliche Kontrolle über die Erzeugung von Klassen. Dieses Video bietet einen Überblick über die Implementierung und den Einsatz von Produzenten.

Transkript

Haben Sie sich schon einmal gefragt, ob es in der CDI für Sie auch Möglichkeiten gibt, mehr Kontrolle über das Erzeugen und das Verwerfen von Objekten zu besitzen? In diesem Video werden wir dieser Frage nachgehen und uns mit Produzenten und Disposern auseinandersetzen. Ohne Produzenten war es in der CDI bisher so, dass wir eine statische Erzeugung von Objekten hatten. Das bedeutet, wir überließen der CDI die Kontrolle darüber, was, wann, wo erzeugt und konfiguriert wird. Für uns war es nicht möglich, eine erzeugte Instanz direkt zu konfigurieren. Das ging zwar indirekt nach Zuweisung, aber eben nicht bei der Erzeugung. Oftmals werden deshalb dynamischere Ansätze benötigt, bspw. wenn der konkrete Typ einer Bean erst zur Laufzeit bekannt ist oder das, was erzeugt werden soll, im strengen Sinne gar keine Bean ist, bspw. eine Zeichenkette oder eine Liste von Zeichenketten. Oder ein Objekt muss von Hand erzeugt werden, weil bspw. die Erzeugung so aufwendig ist oder weiterführende Konfigurationsaufgaben notwendig sind, dass dies an geeigneter Stelle gewährleistet sein muss. Dies alles ist mithilfe von Producern möglich. Der Producer ist damit die Umsetzung des Factory Patterns im CDI-Umfeld. Und der Producer erfüllt die Anforderungen an die Polymorphie, denn wir sind in der Lage, selber zu entscheiden, welche konkrete Objektinstanz von einer Basisklasse erzeugt wird. Die Produzenten selbst sind dabei stets Methoden oder Felder. Und ein Produzent wird immer mit der "Produces"-Annotation versehen. Wenn eine Komponente durch einen Produzenten erzeugt worden ist, dann kann sie wie gehabt injiziert werden. Das bedeutet, wir setzen an die geeignete Stelle eine "Inject"-Annotation. Wichtig: Achten Sie darauf, dass Produzenten eindeutig voneinander unterscheidbar sind. Im obigen Beispiel für eine Liste vom Typ "String" bedeutet dies, dass es genau nur eine einzelne Methode oder ein einzelnes Feld geben darf, dass mit "Produces" annotiert ist und eine Liste vom Typ "String" zurückgibt. Ist dies nicht der Fall, gibt es also mehrere Felder mit der "Producer"-Annotation vom Typ "Liste" vom Typ "String", dann wird es Fehler geben und Ihre Applikation wird nicht mehr starten. Diese Unterscheidung können Sie mithilfe von Qualifiern sicherstellen. Sehen wir uns einmal an, wie Produzenten deklariert und definiert und verwendet werden können. Sie sehen hier die Klasse "KontakteProvider". Diese Klasse erzeugt intern eine Liste vom Typ "String". In Ihrem Konstruktor konfiguriert sie diese Liste. Nun stellt sie uns eine Methode und ein privates Feld zur Verfügung, die beide als Producer dienen können. Wir werden das private Feld als Producer markieren. Zu diesem Zweck fügen wir die "Producer"-Annotation oberhalb dieses Feldes ein, drücken "Strg + Space" und haben dann auch den entsprechenden Import im Kopf der Klasse. Die so definierte "Producer"-Eigenschaft kann nun verwendet werden. Dies geschieht natürlich nicht direkt, sondern stets indirekt. Dies kann z. B. in der Klasse "KontakteManager" stattfinden. Auch hier gibt es eine Methode und eine Variable vom Typ "Liste", vom Typ "String". Wir werden die erzeugte Liste aus dem Kontakte-Provider in die private Member-Variable injizieren lassen. Dies machen wir mithilfe der "Inject"-Annotation. Da es in diesem gesamten Projekt keine weitere Implementierung einer Producer-Methode vom Typ "Liste", vom Typ "String" gibt, wird dieses Projekt problemlos laufen können. Ein anderes Szenario für Produzenten ist es, wenn wir, wie in diesem Beispiel, für den Mock-Kontakte-Provider und für den Test-Kontakte-Provider, Klassen haben, die als "Alternative" annotiert sind. Beide Klassen haben diese Annotation. Dies bedeutet, dass keine dieser Klassen aktiv ist, wenn sie nicht in der Beans.xml als aktiv markiert sind. Nun gibt es aber die Möglichkeit, Alternative-Klassen dennoch zu verwenden, und zwar mithilfe einer Producer-Methode. Sehen wir uns einmal an, wie dies umgesetzt werden kann. Ich habe zu diesem Zweck bereits eine leere Klasse angelegt. Diese Klasse heißt "KontakteProviderFactory". Die Kontakte-Provider-Klasse wird nun eine entsprechende Implementierung einer Produzenten-Methode bekommen. Das ist eine ganz normale Methode vom Typ "KontakteProvider", die ihrerseits mit der "Produces"-Annotation versehen wird. Innerhalb dieser Methode können wir nun die gewünschte Instanz der Klasse erzeugen. In diesem Fall erzeugen wir einen Test-Kontakte-Provider und geben die Instanz am Ende der Methode zurück. Dies entspricht letztlich der Funktionalität, wie sie CDI auch selber bereitstellt. Aber in einer Produzenten-Methode können wir nun den Provider weiter konfigurieren, z. B. indem wir Kontaktnamen hinzufügen. Damit haben wir eine Funktionalität geschaffen, die weit über das hinausgeht, was die CDI selbst leisten kann. Als letztes werde ich dieser Methode noch einen zusätzlichen Qualifier hinzufügen, denn es gibt in meinem Projekt bereits einen aktiven Kontakte-Provider und wir hätten wieder keine Eindeutigkeit gegeben. Aus diesem Grund füge ich einen Qualifier, den ich bereits erstellt habe, den Test-Qualifier einfach der Signatur dieser Methode hinzu. Nun kann ich an geeigneter Stelle den Kontakte-Provider, den ich in der Kontakte-Provider-Factory erzeugen lasse, injizieren lassen. Dies mache ich in der Kontakte-Manager-Klasse, d. h. ich notiere hier die "Inject"-Annotation und notiere ebenfalls die "Test"-Annotation. Und obwohl beide Kontakte-Provider als Alternativen gekennzeichnet sind, besteht nun die Möglichkeit, dass über das Producer-Pattern eine Instanz erzeugt wird. Ein weiterer Aspekt bei der Verwendung von Produzenten ist, dass Produzenten oft für einen Typ-sicheren und eindeutigen Zugriff auf Ressourcen, also bspw. Datenbanken oder ähnliche Komponenten genutzt werden können. Schlechter Stil ohne Produzent könnte dies sein, d. h. wir haben eine Entity-Manager-Eigenschaft, die mit der Persistence-Kontext-Annotation versehen ist. Was daran jetzt unklar und schlecht ist? Nun, an der Stelle besteht keine Typ-sichere Zuweisung eines Persistence-Kontext und keine eindeutige Zuweisung. Besser ist es, wenn wir eine Produzenten-Methode definieren. In diesem Fall gibt es eine Eigenschaft "EntityManager", die mit der "Produces"-Annotation versehen ist und mit dem Qualifier "CustomerDatabase". Und die Verwendung dieser entsprechend erzeugten Komponente geschieht dann mit "Inject" und "CustomerDatabase"-Annotationen. An dieser Stelle ist dann sichergestellt, dass tatsächlich nur diese eine spezifische Entity-Manager-Instanz verwendet wird. Das ist auf jeden Fall eindeutiger als der Ansatz, den wir zuvor gesehen haben. Das Gegenstück zu einem Produzenten ist ein Disposer. Ein Disposer ist eine spezielle Methode, die zum Aufräumen gedacht ist. Diese wird mithilfe der "Disposes"-Annotation gekennzeichnet. Ein Disposer wird immer zusammen mit einem Produzenten verwendet und wird automatisch aufgerufen, wenn der Lebenszyklus der erzeugten Bean endet. Ein Beispiel: Wir erzeugen im oberen Bereich eine Entity-Manager-Instanz und im unteren Bereich in der Closed Methode gibt es, für genau diese Entity-Manager-Instanz, auch erkennbar über den Qualifier "UserDatabase", eine Disposes-Annotation. Diese Annotation ist auf Ebene des Parameters der Methode definiert. Damit haben wir einen Disposer geschrieben und wenn der Entity-Manager von dem System verworfen wird, wird automatisch diese Methode "close" aufgerufen. Das macht schon Sinn, das Ganze so zu handhaben. Wir haben in diesem Video kennengelernt, wie wir die Erzeugung von Komponenten steuern können und wie wir auch das Aufräumen automatisch gewährleisten können. Sie sollten das erlernte Wissen in Ihren Projekten unbedingt anwenden.

Java EE 7 Grundkurs

Lernen Sie die Grundlagen der Programmierung mit Java EE 7 verstehen und anwenden.

6 Std. 4 min (44 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Software:
Exklusiv für Abo-Kunden
Ihr(e) Trainer:
Erscheinungsdatum:07.11.2014
Laufzeit:6 Std. 4 min (44 Videos)

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!