dsentker

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?

__________________

Mister Ad

tr0y

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.

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

dsentker

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?

__________________

tr0y

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

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

dsentker

Interessant:
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?

__________________

tr0y

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.

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

dsentker

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?

__________________

tr0y

Jupp.

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.