Entity-Services ein Antipattern?

erdmann

Mitglied
Hallo,

ich bin gerade dabei mich in JavaEE im allgemeinen und JPA im speziellen einzuarbeiten. Dabei hantiere ich parallel mit verschieden Büchern.

In meine Hauptinformationsquelle zu JPA ist das Buch "Java Persistence API 2 - Hibernate, EclipseLink OpenJPA und Erweiterungen" Bernd Müller, Harald Wehr, 2012

Dort findet sich folgendes Zitat (S. 101):

"JPA erlaubt den Entwurf von Domain-Models bzw. Rich Domain-Models im Gegensatz zu Anemic Domain-Models. Ein Anemic Domain-Model realisiert Anwendungsobjekte ausschließlich über Getter und Setter und lagert die Anwendungslogik in separate Klassen aus. Diese Art der Modellierung wurde z. B. durch das Entity-Modell der frühen EJB-Spezifikationen gestärkt, die Rich Domain-Models nicht oder nur unzureichend unterstützten. Mit der Einführung von JPA 1.0 gibt es keinen Grund mehr, ein Anemic Domain-Model zu verwenden, und wir raten dem Leser ausdrücklich, Rich Domain-Models zu erstellen. Martin Fowler bezeichnet das Anemic Domain-Model ausdrücklich als Anti-Pattern [...]".

In meinen Büchern zu JavaEE im Algemeinen findet sich, glaube ich, genau dieses Pattern aber immer wieder. Etwa in "Workshop Java EE 7" von Marcus Schießer und Martin Schmollinger gibt es zu jeder Entity-Klasse eine ServiceBean. Die Entities enthalten nur Setter, Getter und NamedQuerys, die ganze Logik und die Methoden zum Peristieren und Löschen finden sich jeweils in einer zugehörigen ServiceBean (die ein passendes Interface implementiert).

Wie haltet ihr es damit bzw. eure Arbeitgeber. Rich-Domain-Models oder ServiceBeans? Oder habe ich etwas falsch verstanden und es gibt hier gar keinen Widerspruch zwischen beidem?
 
Zuletzt bearbeitet:

stg

Top Contributor
Im Grunde eigentlich nur wieder eine der vielen Glaubensfragen. Genauso wie "DTOs - ja oder nein? "

Um Service-Klassen wirst du nicht komplett drumherum kommen, aber das hält dich nicht davon ab, in den Entity-Klassen selbst auch Geschäftslogik abzubilden. Zum Beispiel das Auswerten abgeleiteter Attribute, das setzen von Beziehungen, Validierungen, Builder....

Ich selbst wähle meist einen Kompromiss aus beiden Ansätzen. Rich-Domain-Models sind z.B. leichter testbar, wenn gar kein EntityManager mehr involviert ist.

Später vielleicht auch ein wenig ausführlicher, nun erst mal ab nach Hause.

Den Blog-Eintrag von Fowler findest du übrigens hier: http://martinfowler.com/bliki/AnemicDomainModel.html
Auch interessant (und kurz und knapp): http://www.adam-bien.com/roller/abien/entry/10_tips_on_jpa_rich
 

erdmann

Mitglied
Viele Dank für Deine Antwort und die Links,

Die Tipps von Adam Bien sind nützlich für mich.

Dein Rat lautet also: Was inhaltlich ins Entity gehört, sollte man - wenn möglich - auch dort umsetzen. Das geht aber nicht immer, insbesondere dann nicht, wenn man den EntityManager benötigt. In solchen Fällen geht's nicht ohne Serviceklasse. Richtig?
 

stg

Top Contributor
So handhabe ich das, ja. Aber du wirst sicherlich nicht wenige Leute finden, die mir da komplett wiedersprechen werden.

Wie so oft, gibt es auch hier kein allgemein gemültiges Richtig oder Falsch, sondern es ist oft immer wieder eine Einzelfall entscheidung. Und nicht zuletzt auch persönlicher Stil.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
OnDemand Vorgehen DB /Entity Data Tier 2
A Entity Manager Data Tier 4
S JPA Cascade: Entity nur speichern, wenn sie nicht schon existiert Data Tier 0
E JPA Session.delete einer Entity wird nicht ausgeführt Data Tier 2
G JPA: Entity Klasse @JoinColumns Problem Data Tier 2
G EJB NoSuchEJBException Zugriff auf Entity Data Tier 6
S [JPA-Neuling] - JPA 2 und dynamische Entity-Typen/DB-Schemata Data Tier 11
Landei JPA - Entity mit Maps Data Tier 2
H [Hibernate] Unknown Entity Data Tier 3
G JPA/ Eclipselink: (Alte) Kopie einer Entity? Data Tier 6
J Servlet mit eigenem Entity-Manager innerhalb von Seam-Projekt Data Tier 3
lumo Hibernate - entity class not found Data Tier 5
J synchronisierte Zugriffe auf die gleiche Entity (JPA) Data Tier 19
LCS Entity mit variablen Tabellennamen Data Tier 3
D jpq entity life cycle - insert, update... Data Tier 5
A @org.hibernate.annotations.Entity(dynamicUpdate=true, optimisticLock=OptimisticLockType.ALL) Data Tier 2
T [JPA] Update Entity in Entity Data Tier 2
byte Hibernate: Criteria & SubQuery - Unknown Entity null Data Tier 1
Final_Striker EJB3: Entity nach persist wiederfinden Data Tier 8
N Entity-Object muss auf Client aktualisiert werden Data Tier 13
0 org.hibernate.MappingException: Unknown entity Data Tier 8
K Hibernate: Unknown entity Data Tier 7

Ähnliche Java Themen

Neue Themen


Oben