Businessmethoden in einer Entität zum bidirektionalen Speichern?

[chrisbad]

Hallo Experten,

ich habe mal wieder eine (wahrscheinlich etwas dämliche) Anfängerfrage ;-)

Und zwar ist doch der Grundgedanke des objektorientierten Programmierens der, dass Objekte Dinge aus der Realität abbilden und deren Eigenschaften und Methoden beschreiben.
Nun habe ich eine ganze Reihe von Entitäten (Glassfish/JPA/Eclipselink) die ja eigentlich schon ganz gut meine Objektstruktur abbilden.

Nun habe ich bis jetzt in den Entitäten immer nur Getter und Setter gesehen, aber nie echte Methoden zum manipulieren des Objekts.

Frage 1:
In meinem Fall gibt es z. B. 2 Objekte - Company und User. Was spricht dagegen in Company und User Businessmethoden zu implementieren?

Frage 2:
Die Beziehung zwischen beiden Objekten soll bidirektional sein und ich hätte in Company gerne eine Methode addUser().
Grob skiziert würde dies ja so aussehen:

public void addUser(User user) {
this.users.add(user);
user.setCompany(this);
}

Nun müsste ich ja beide Objekte speichern. Dazu wiederum müsste ich mir in die Entität einen EntityManager holen und hier dann beide speichern. Irgendwie fühlt sich das für mich nicht richtig an.
@PersistenceContext in einer Entität? Wie mache ich das richtig?

Versteht ihr was ich meine?

LG Chris

 

[maki]

In meinem Fall gibt es z. B. 2 Objekte - Company und User. Was spricht dagegen in Company und User Businessmethoden zu implementieren?

Gar nichts, aus OOP Sicht wäre das auch die Norm.

}Frage 2:
Die Beziehung zwischen beiden Objekten soll bidirektional sein und ich hätte in Company gerne eine Methode addUser().
Grob skiziert würde dies ja so aussehen:

Das wäre dann wohl die "owning side".

 

[Landei]

Die Idee ist eine gewisse Entkopplung von der jeweiligen Technologie. Du hast dein Modell, das dein Problem abbildet, und von der restlichen Welt nichts wissen sollte. Deine Modellklasse verwendet vielleicht spezielle Datentypen, die in der Datenbank nicht vorgesehen sind. Zwar bieten moderne Frameworks wie Hibernate auch Möglichkeiten, damit umzugehen, trotzdem hat es sich in der Praxis als flexibler, transparenter und robuster erwiesen, diese Übersetzung zwischen problemorientierter und persistenzorientierter Sicht selbst vorzunehmen. Z.B. sollte der Wechsel des Persistenz-Frameworks keine Änderungen an den Modell-Klassen nach ziehen.

Generell kann man konstatieren, dass man zur Entkopplung externer "Interessenten" unterschiedliche Sichten auf ein Modell-Objekt benötigt: Eine Sicht für die Persistenz, eine Sicht für das Reporting, eine Sicht für die Darstellung als HTML, PDF u.s.w., und dementsprechend für jede dieser Sichten spezielle "Adapter" anbietet. Diese Adapter sind dann in der Regel ziemlich "dumm", weil sie bestimmte Aspekte des Modells stupide in ihre spezifische Domäne übersetzen. Siehe z.B. The Entity-Control-Boundary Pattern (insbesondere die hexagonale Architektur)