Doctrine2 Domänenobjekte

[Mr.H]

Schreibe gerade an einem Artikel. Bin mir aber nicht sicher ob das korrekt ist, was ich da Behaupte. Deshalb wäre es toll, wenn das mal jemand bestätigen oder wiederlegen könnte.

Data Mapper (nach Fowler) ist ein Objekt, das eine Abbildung zwischen Datenbankstrukturen und Programmstrukturen vornimmt (objekt-relationale Abbildung). So sind komplexe Transformationen möglich, die Ergebnis-Klassen enthalten keinerlei Persistenz-Code mehr und echte Domänen-Objekte oder Daten-Transfer-Objekte, die nur Datenbehälter sind, können erzeugt werden.

Sind diese "Ergebnis-Klassen" das gleiche wie die "Domänen-Objkete"?
Und wenn ja sind dann diese Domänen-Objekte dann konkret in Doctrine2 so was hier?

<?php
/**
 * @Entity @Table(name="products")
 */
class Product
{
    /** @Id @Column(type="integer") @GeneratedValue */
    public $id;
    /** @Column(type="string") */
    public $name;
}

Und wenn nein, was ist dieser Code dann? Und was ist in Doctrine2 dann ein Domänen-Objekt bzw. Ergebnis-Klasse?

[dr.e.]

Schau dir nochmal das domain object pattern an. Domänen Objekte repräsentieren Daten + Logik und delegieren lediglich die Persistenz nach aussen (zumeist über Entity-Manager oder Data-Mapper realisiert). Per se ist jedoch Persistent ein Thema eines Domänen-Objektes bzw. kommt dieses damit in Berührung. Insofern ist die Aussage nicht korrekt.

Im Prinzip gibt es zwei Ansätze: echte Domänen-Objekte und DTO + Mapper wobei der Mapper dort im Vordergrund steht (="Ansprechpartner" für eine Business-Komponente). Weiterer Unterschied zwischen dem Domänen-Objekt-Konzept und DTO + Mapper ist, dass ein Domänen-Objekt die Geschäftslogik implementiert und bei DTO + Mapper meist eine Business-Komponente nach dem transaction script pattern hinzukommt.

Doctrine2 und auch beispielsweise der GORM des APF generieren Domänen-Objekt-Hüllen, die du dann mit Leben (=Geschäftslogik) füllen musst.

[Mr.H]

Danke dr.e.
Also, Doctrine2 benutzt Domänen-Objekte in welche ich meine Geschäftslogik schreibe?!
Und diese Geschäftslogik ist dann im Grunde so was wie der obere PHP Code, aber auch sowas wie Abfragen bzw. Manipulationen im Gesamten?

[joshiausdemall]

Schau dir nochmal das domain object pattern an. Domänen Objekte repräsentieren Daten + Logik und delegieren lediglich die Persistenz nach aussen (zumeist über Entity-Manager oder Data-Mapper realisiert). Per se ist jedoch Persistent ein Thema eines Domänen-Objektes bzw. kommt dieses damit in Berührung. Insofern ist die Aussage nicht korrekt.

Im Prinzip gibt es zwei Ansätze: echte Domänen-Objekte und DTO + Mapper wobei der Mapper dort im Vordergrund steht (="Ansprechpartner" für eine Business-Komponente). Weiterer Unterschied zwischen dem Domänen-Objekt-Konzept und DTO + Mapper ist, dass ein Domänen-Objekt die Geschäftslogik implementiert und bei DTO + Mapper meist eine Business-Komponente nach dem transaction script pattern hinzukommt.

Doctrine2 und auch beispielsweise der GORM des APF generieren Domänen-Objekt-Hüllen, die du dann mit Leben (=Geschäftslogik) füllen musst.

Häh? Könntest Du das vielleicht noch ein wenig ausbauen? Ich habe den Eindruck, dass da einige Begriffe mindestens durcheinandergeworfen wurden - oder aber ein gewisser akademischer Hintergrund gängige Begrifflichkeiten synonym behandelt. Letztlich ist es nicht oder nur kaum zu verstehen.

Zur Frage des TE: Der Data Mapper sorgt dafür, dass die entsprechenden Ergebnisdatensätze aus den Datenbankabfragen an ein relationales DBS auf eine gewisse Datenstruktur (exemplarisch eben ein Objektgraph) abgebildet wird.

Und ja, die "Ergebnisklassen" sind letztlich "Domänenobjekte" (was prinzipiell alles heißen kann), "Entity" wäre ein besserer Begriff - ein Entity entspricht grob einem Tupel der Resultset. Also das, was hinten ´raus kommt.

Es gibt zwei "konkurrierende", gängige Implementierungen: Das Active Record Pattern (siehe bspw. RoR oder auch Doctrine 1): Mapping der Daten auf eine komplexe Struktur, jedes "Active Record" erweitert eine abstrakte Basisklasse, die CRUD-Funktionalität bereitstellt:

$car = CarProvider::find(1);
$car->setName('Audi');
$car->save();

Demgegenüber steht das optimierte UnitOfWork-Pattern, das einen Entity-Manager implementiert:

$audi=new Car('Audi 80');
$obbel = new Car('Opel Manta');

$em->persist($audi);
$em->persist($obbel);

$em->flush(); // schießt ein optimiertes, transaktional gekapseltes INSERT ab

Doctrine 2 wie auch bspw. Hibernate folgen dem letztgenannten Muster. Entities sind immer Pojos respektive Popos. (bzw - je nach Hydration Mode - auch einfach nur Arrays).

ActiveRecord vermischt Methoden zur Persistierung mit den Domänenobjekten ($car->save()), UnitOfWork trennt beides sauber voneinander.

BEIDE allerdings bedienten sich sogenannter "Provider" bzw. Data Access Objects, um Geschäftslogik zu kapseln ($mantas = $myCarDao->findAllCarsWithFuchsschwanz()).

[dr.e.]

Häh? Könntest Du das vielleicht noch ein wenig ausbauen? Ich habe den Eindruck, dass da einige Begriffe mindestens durcheinandergeworfen wurden - oder aber ein gewisser akademischer Hintergrund gängige Begrifflichkeiten synonym behandelt. Letztlich ist es nicht oder nur kaum zu verstehen.

Da wir im Software-Design-Forum sind ist es doch sicher zulässig, auf akademischer Ebene zu argumentieren. Sollte dir etwas Hintergrund-Wissen dazu fehlen, empfehle ich Martin Fowlers Werke zu Gemüte zu führen.

Und ja, die "Ergebnisklassen" sind letztlich "Domänenobjekte" (was prinzipiell alles heißen kann), "Entity" wäre ein besserer Begriff - ein Entity entspricht grob einem Tupel der Resultset. Also das, was hinten ´raus kommt.

Eben nicht! Domänen-Objekt != Entity != Ergebnis-Klasse.

Es gibt zwei "konkurrierende", gängige Implementierungen:

AR ist ein Modell, das "value objects" oder "data transfer objects" ausspuckt. Diese sind jedoch noch keine Domänen-Objekte, sondern können lediglich von einem genutzt als Mittel zur Abbildung der Persistenz genutzt werden.