Java EE 7: Geschäftsanwendungen

Daten-Layer anlegen

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Im Java-EE-Umfeld wird der Zugriff auf Entitäten in aller Regel über einen dedizierten Daten-Layer in Form einer Stateless Session Bean umgesetzt. Lernen Sie hier, welche Arten bzw. Sichten es auf Stateless Session Beans gibt.

Transkript

Möchte eine Java-EE-Applikation mit Daten arbeiten, also Entities laden, speichern oder manipulieren, dann macht sie dies üblicherweise über den sogenannten Datenbank-Layer oder Data-Layer. So ein Data-Layer ist eine Stateless Session Bean in aller Regel. In diesem Video werden wir uns deshalb damit auseinander setzen, was eine Stateless Session Bean ist, wie wir Sie implementieren können und wir werden Stateless Session Bean so vorbereiten, dass wir sie als Data-Layer benutzen können. Stateless Session Beans sind POJOs, Plain Old Java Object, ganz normale Java-Klassen, die halt im Kontext der Java EE auf dem Application Server deployed werden. Sie halten kein Zustand vor. Das bedeutet, Sie sind sehr effektiv verwendbar, denn ein Application Server muss nichts zwischen irgendwelchen Cluster Membern hin und her synchronisieren. Aus diesem Grund bilden Stateless Session Beans in aller Regel die klassische Geschäftsschicht einer Java-EE-Applikation. Wenn wir eine Stateless Session Bean schreiben, schreiben wir in aller Regel eine ganz normale Klasse. Diese Klasse ist ein mit der @Stateless-Annotation versehen. Diese Annotation sorgt nun dafür, dass ein Client, der mit dieser Klasse arbeiten möchte, automatisch ein Proxy generiert, wenn er diese Bean anspricht. Und dieser Proxy stellt uns alle öffentlichen Methoden der Klasse bereit. In den Client binden wir die EJB in aller Regel mit Hilfe der @EJB-Annotation ein. So eine Klasse, die mit @Stateless annotiert ist und vom Client genutzt wird, hat eine Sicht auch Ihre Methoden und diese Sicht nennt sich No Interface View. No Interface View deswegen, weil diese Sicht nicht eingeschränkt ist, sondern eben alle öffentlichen Methoden umfasst. Üblicherweise möchte man das allerdings nicht, sondert man verwendet eine spezifische Sicht nämlich die Remote Sicht, den Remote View. Der Remote View mit Hilfe der @Remote-Annotation gekennzeichnet. Und diese Kennzeichnung wird auf Ebene eines Interfaces notiert oder mit einem Interface verwendet, das wir einbinden. Sobald das geschieht, sobald wir auf einer Stateless Session Bean ein @Remote View anootiert haben, ist der Proxy, der erzeugt wird beim Client immer vom Typ des Interfaces, nicht mehr vom Typ der eigentlichen Klasse. Der Vorteil dieses Ansatzes ist, dass wir nun genauer definieren können was ein Client nutzen kann, nämlich nur noch alle Methoden, die auf Ebene des Interfaces definiert sind. Und weil wir ein Interface definieren, sind wir sehr entkoppelt von der eigentlichen Implementierung des Stateless Session Bean und können diese Bea dann auch außerhalb der aktuellen Java-EE-Approkation nutzen. Nun ist es allerdings so, dass man gerne für Komponenten, die innerhalb der selben Java-EE-Applikation laufen, weitere Funktionalitäten, zusätzliche Funktionalitäten bereitstellen möchte. Dies kann man machen, indem man ein Local View erzeugt. Der Local View ist wiederum ein Interface, eine Schnittstelle, versehen mit der @Local-Annotation. Und wenn wir schon ein Remote View haben, der letztlich für externe Komponenten, die Sicht auf verfügbare Methoden umsetzt, haben wir mit Hilfe des Local Views die Möglichkeit, dass wir für interne Komponenten, also andere EJB Komponenten innerhalb der selben Applikation mehr an Funktionalitäten bereitstellen können. Oftmals ist es allerdings nicht so sehr gewünscht, dann halt neben einem Remote Interface auch noch ein Local Interface zu definieren und aus diesem Grund gibt es nicht die @LocalBean-Annotation. Die @LocalBean-Annotation wird nicht auf Ebene eines Interfaces definiert, sondern direkt auf der Klasse, also dort, wo auch die @Stateless-Annotation steht. Und damit drücken wir aus, dass es zwar eine Remote View gibt, also eine Sicht gibt die Remote Client nutzen müssen, dass es aber auf der anderen Seite auch eine lokale Sicht gibt und diese lokale Sicht sind einfach alle öffentlichen Methoden dieser Klasse. Das ist also ein sehr nützlicher Ansatz, den man dann auch gezielt einsetzt. Der Lebenszyklus einer Stateless Session Bean ist übrigens sehr sehr einfach, Weil der Server im Grunde nicht weiter machen muss als diese Beans in irgendeiner Art und Weise vorzuhalten, erzeugt er sie. Er legt sie in einen Pool von Beans, üblicherweise hält der Server also einige Beans schon im voraus vor, damit Sie eben nicht erst bei der Anfrage erzeugt werden müssen und nutzt sie so lange, wie sie benötigt werden. Irgendwann wird diese Bean dann verworfen, weil Sie nicht mehr benutze werden muss und wir aus dem Pool entfernt. Wir werden nun in unserer Applikation eine Stateless Session Bean definieren, die als Data-Layer funktioniert. Wir werden dabei dieser Stateless Session Bean einen Entity Manager injizieren und wir werden einige Methoden bereitstellen. Diese Methoden werden wir an dieser Stelle noch nicht weiter implementieren, aber sie eben schon definieren. In unserer Applikation legen wir nun zunächst einmal das Interface, das Remote Interface an. Zu diesem Zweck legen wir über das Kontextmenü ein neues Interface an mit dem Namen "CustomerDAO". DAO steht für Data Access Object. Das ist eine ziemlich alte Abkürzung, die sich aber in der Java EE bis heute behalten hat. Dieses CustomerDAO wird einige Methoden haben, nämlich die Methode "Create", die einen Kunden erzeugt, die Methode "Update", die einen Kunden updatet, die Methode "Remove", die einen Kunden löscht und die Methode "getCustomer", die uns einen spezifischen Kunden zurückgibt, identifiziert über seinen Primärschlüssel, sowie die Methode "getAllCustomers", die uns eine Liste aller vorhandenen Customers zurückgibt. Dieses Interface können wir nun optional mit der @Remote-Annotation versehen. Das wäre eine Möglichkeit damit auszudrücken, dass es sich hier um die Remote View handelt. Wenn wir hier "@Remote" rüberschreiben, sind wir allerdings darauf festgelegt, dass dieses Interface immer ein Remote Interface ist, und vielleicht möchte man es unter Umständen nicht, deswegen geht man einen anderen Weg, in aller Regel, man fügt diese Annotation hier nicht hinzu, sondern dann erst auf Ebene der Bean. Die Bean definieren wir im Package "com.cm.ejb.beans", das Interface lag im Package "com.cm.ejb.interfaces". Die Bean wir angelegt als eine neue Klasse und wir nennen sie "CustomerBean". Diese Klasse "CustomerBean" wird nun mit der @Stateless-Annotation versehen und sie bekommt die @Remote-Annotation zugewiesen und hier geben wir jetzt den Typ des Interfaces an, nämlich CustomerDAO.class und damit wird für die EJB Clients ausgedrückt, dass das Remote Interface "CustomerDAO" zu verwenden. Dieses Interface müssen wir nur noch implementieren und das machen wir, indem wir das entsprechende Implement Statement notieren und dann uns die Methoden generieren lassen. Nun müssen wir lediglich noch den PersistenceContext injizieren lasse. Das machen wir in eine Variable vom Typ EntityManager. Und das erreichen wir, indem wir @PersistenceContext-Annotation oberhalb oder an dieser privaten Member-Variablen notieren. Nun können wir im nächsten Schritt hingehen und alle notwendigen Funktionalitäten des Entity Managers implementieren. In diesem Video haben wir eine Stateless Session Bean angelegt mit dem Namen "CustomerBean". Diese CustomerBean implementiert das CustomerDAO Interface und das ist ein Remote Interface, was wir mit Hilfe der @Remote-Annotation ausgedrückt haben. Wir haben ebenfalls besprochen welche Formen von Stateless Session Beans mit ihren verschiedenen Sichten es gibt, nämlich die NoInterface View, die Local View und die Remote View. Und wir haben auch besprochen, was die @LocalBean-Annotation für uns an Möglichkeiten bietet.

Java EE 7: Geschäftsanwendungen

Verfolgen Sie, wie eine komplette Business-Applikation unter dem Einsatz des gesamten Java-Enterprise-Techologiestacks ensteht.

5 Std. 2 min (39 Videos)
Derzeit sind keine Feedbacks vorhanden...

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!