Entity-Services ein Antipattern?

Dieses Thema Entity-Services ein Antipattern? im Forum "Data Tier" wurde erstellt von erdmann, 16. Dez. 2015.

Thema: Entity-Services ein Antipattern? Hallo, ich bin gerade dabei mich in JavaEE im allgemeinen und JPA im speziellen einzuarbeiten. Dabei hantiere ich...

  1. 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: 16. Dez. 2015
  2. Vielleicht hilft dir das Grundlagen Training weiter --> *Klick*
  3. stg
    stg
    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
     
  4. 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?
     
  5. stg
    stg
    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.
     
  6. Kostenloses Java-Grundlagen Training im Wert von 39 €
    Schau dir jetzt hier das Tutorial an und starte richtig durch!