Einführung
Diese Richtlinie konzentriert sich auf das Festlegen von Entity-Beans. Nähere Informationen zu Entity-Beans finden Sie
unter Richtlinie: Entity-Bean. Allgemeine Anleitungen zu EJBs finden Sie unter Richtlinie: Enterprise JavaBean (EJB)
Entity-Beans festlegen
Entitätsanalyseklassen (siehe Analyseklasse) eignen sich meist gut für Entity-Beans, weil
Entity-Beans dafür eingerichtet sind, Daten persistent zu speichern. Entity-Beans entsprechen Geschäftsentitäten, die
einen persistenten Status enthalten. Sie stellen Services bereit, die die für die Geschäftsentität spezifische Logik
implementieren. Ein weiteres Merkmal von Entity-Beans ist ihre Fähigkeit, ihre Services für viele simultane Clients
bereitzustellen. Der EJB-Container steuert die Koordination dieser Clients und ihre Transaktionen.
Entity-Beans werden verwendet, um Persistenz zu erzielen. Sie können aber auch die Geschäftslogik enthalten.
Normalerweise sollte eine Entity-Bean nur die Geschäftslogik enthalten, die zu den von der Entity-Bean persistent
gespeicherten Daten und zugehörigen Datenobjekten gehört. Die Logik zwischen den Entity-Beans sollte in eine
Session-Bean extrahieren werden, um die Verkopplung zwischen Entity-Beans zu minimieren.
Entity-Beans modellieren
Siehe Richtlinie: Enterprise JavaBeans (EJBs) festlegen.
Unterteilung
Die Unterteilung bezieht sich auf die Größe der von der Entity-EJB dargestellten Daten. Die geeignete Unterteilung kann
abhängig sein von der verwendeten Version der EJB-Spezifikation.
Vor EJB 2.0 wurde für EJBs eine große Unterteilung empfohlen, die normalerweise große Gruppierungen der in mehrere
Datenbanktabellen gruppierten Daten darstellen sollte. Der Grund dafür ist der, dass jede Entity-EJB erhebliche
Overheads enthielt, insbesondere Overheads, die sich auf die Verwendung von fernen Schnittstellen bezogen.
Beispielsweise sind die Positionen einer Rechnung oder die Zellen in einem Spreadsheet zu differenzierte Elemente, die
nicht häufig über ein Netz abgerufen werden sollten. Im Gegensatz dazu könnten logische Gruppierungen der
Rechnungspositionen oder eine Untermenge der Zellen in einem Spreadsheet als Entity-EJB modelliert werden, falls
zusätzliche Geschäftslogik für die Daten erforderlich ist.
Dies ändert sich etwas in EJB 2.0. Die Einführung von lokalen Schnittstellen reduziert einige dieser Overheads und
erlaubt es, dass differenziertere Objekte als EJBs modelliert werden. Eine Beschreibung der lokalen und fernen
Schnittstellen finden Sie unter Konzept: Überblick über Java 2 Platform Enterprise Edition (J2EE). Eine lokale
Schnittstelle besitzt nicht den Overhead einer fernen Schnittstelle und erlaubt dadurch eng verbundenen Beans
effizienter zu interagieren. Lokale Schnittstellen sind besonders hilfreich für differenzierte Entitäten, die zur
Bildung einer größeren Entität verwendet werden, wobei die größere Entität zuständig ist für das Erstellen und
Zerstören ihrer Teile. Clients verwenden die ferne Schnittstelle der größeren Entität, die wiederum die lokalen
Schnittstellen verwendet, um mit ihren Teilen zu interagieren.
Trotzdem gilt: Wenn eine Entity-Bean in ihrer Zusammensetzung abhängig ist von einer anderen Klasse, dann können Sie
diese andere Klasse als logische Java-Klasse anstatt als Entity-Bean modellieren. Bei Verwendung der über Container
realisierten Transaktionspersistenz wird eine solche Java-Klasse als "abhängige Wertklasse" bezeichnet. Entwicklung und
Test von abhängigen Wertklassen sind einfacher und schneller als bei Entity-Beans und sie sind eine gute Wahl,
vorausgesetzt, die erstellte Klasse erfordert keine Entity-Bean-Features. Abhängige Werteklassen haben einige
Einschränkungen:
-
Sie können keine Entity-Bean-Referenzen enthalten.
-
Sie werden über einen Wert abgerufen ("get") und festgelegt ("set"). Dies erfordert zwar mehr Leistung, erlaubt
jedoch den Zugriff über die ferne Schnittstelle.
Kapselung
Sie können eine Gruppe von zusammengehörigen Entity-Beans in eine Session-Bean-Fassade verpacken, um eine logische
Schnittstelle zur Bearbeitung der Geschäftsentitäten bereitzustellen, die den Entity-EJBs entsprechen. Siehe hierzu Richtlinie: Session-Bean festlegen.
Eine ähnliche Lösung ist die Kapselung einer Gruppe von lokalen Entity-Beans in einer Entity-Bean, von der sie
normalerweise abhängig sind. Ferne Clients greifen über die "Haupt"-Entity-Bean auf alle Daten zu. Diese Alternative
wird in Core J2EE Patterns - Composite Entity Pattern ([ALU01]) erläutert. Allerdings wird die Session-Bean-Fassade als einfachere Methode
zur Steuerung der Entity-Bean-Abhängigkeiten empfohlen.
|