Unterschiede zwischen Entities, Models und DomainObjects

[Forumsgast]

Huhu,

als "Model" bezeichnete ich immer eine Klasse, die Daten, etwa aus einem Repository, repräsentiert. Dabei stellt sie getter- und setter-Methoden bereit.

In diesem Zusammenhang laufen mir aber auch immer wieder zwei andere Begriffe über den Weg: Entities und DomainObjects.

Wer kann mir den Unterschied bzw. den Zusammenhang dieser drei Begriffe erklären?

[Forumsgast]

Models sind Strukturen die Businesslogik enthalten und Daten aus bspw. Repositories repräsentieren.

DomainObjects sind Models die sich selbst mit anderen DomainObjects vergleichen können, mit ihrer "Domäne" interagieren können ( und sollen ! ) und sich selbst warten können.

Entities sind Datenrepräsentationen die zwar ähnlich der Models und DomainObjects auf Datenresourcen zugreifen ( Repositories, ... ) in ihrer Natur aber reale Entitäten ( man möge es Gruppierte Daten nennen ) wie bspw. "Mitarbeiter", "Auto" oder "Polizei-Hundertschaft" nach bilden. Real mag hier etwas bindend klingen, soll aber nur beispielhaft für die Art und Weise der Gruppierung als Stellvertreter einstehen.

[Forumsgast]

Das verwirrt mich ehrlich gesagt nur noch mehr. Seit wann dürfen Models Businesslogik enthalten? Wofür sollte man ein DomainObjekt mit einem anderen Vergleichen? Und sind Entities, die du beschreibst, nicht z.B. Collections bei Doctrine?

[Forumsgast]

domain object:
http://de.wikipedia.org/wiki/Gesch%C3%A4ftsobjekt

entity:
http://de.wikipedia.org/wiki/Entit%C3%A4t_(Informatik)

Collections ist eine Art Entität, ja, allerdings sind Collections eher Datensatzbasierende Entities.

http://de.wikipedia.org/wiki/Model_View_Controller

Modell (model) [Bearbeiten]
Das Modell enthält die darzustellenden Daten und gegebenenfalls (abhängig von der Implementierung des MVC-Patterns) auch die Geschäftslogik. Es ist von Präsentation und Steuerung unabhängig. Die Bekanntgabe von Änderungen an relevanten Daten im Modell geschieht nach dem Entwurfsmuster „Beobachter“. Das Modell ist das zu beobachtende Subjekt, auch Publisher, also „Veröffentlicher“, genannt.

[Forumsgast]

Interessant:

Geschäftsobjekte enthalten nicht nur Daten (s. u. Abgrenzung zu Entitäten), sondern auch Verarbeitungslogik.

Das hilft mir weiter. Danke für die Links.

Wenn ich also ein Model habe, dass eine bestimmte Position einer Rechnung (inklusive Menge, Artikelnr, Preis etc) repräsentiert, und ich möchte mir den Gesamtwert ausrechnen, spendiere ich diesem Model die Methode "BerechneGesamtWertDieserZeile()" und dann nennt es sich DomainObject?
Oder wäre die richtige Vorgehensweise ein DomainObject, das im Konstruktor ein Model erwartet, mit dessen Daten es rechnen kann?

[Forumsgast]

Nein, DomainObjects sind keine form von Datenproxy, sondern ein Model. Und ja du kannst dem Model durchaus Berechnungs-Methoden geben, pro Zeile aber nicht, dann bist du bei einem DataSet- / RecordSet- / Iterator-Object, das wiederum DomainObjects / Entities zurückgeben könnte und von einem Model ausgeliefert würde.

[Forumsgast]

Warum denn nicht pro Zeile? Irgendwo brauche ich doch eine Methode, die mir den Gesamtwert der Rechnungs-Zeile zurückgibt? (Also quasi return $this->preis * $this->menge). Egal, wo ich diese Methode hinsetze- es macht die Klasse doch dann automatisch zu einem DomainObject?

[Forumsgast]

Jupp.