php.de

Zurück   php.de > Webentwicklung > Software-Design

Software-Design Diskussionen auf Profi-Niveau: PHP Lösungen auf konzeptioneller Ebene

Antwort
 
LinkBack Themen-Optionen Thema bewerten
Alt 22.09.2011, 21:21  
Neuer Benutzer
 
Registriert seit: 02.12.2010
Beiträge: 11
PHP-Kenntnisse:
Fortgeschritten
Mr.H befindet sich auf einem aufstrebenden Ast
Mr.H eine Nachricht über Skype™ schicken
Standard Doctrine2 Domänenobjekte

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.
Zitat:
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-Code:
<?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?
Mr.H ist offline   Mit Zitat antworten
Sponsor Mitteilung
PHP Code Flüsterer

Registriert seit: 21.08.2005
Beiträge: 4682
PHP-Kenntnisse:
Fortgeschritten

Alt 22.09.2011, 22:41  
Moderator und Wett-König
 
Benutzerbild von dr.e.
 
Registriert seit: 21.05.2008
Beiträge: 3.657
PHP-Kenntnisse:
Fortgeschritten
dr.e. ist ein Lichtblickdr.e. ist ein Lichtblickdr.e. ist ein Lichtblickdr.e. ist ein Lichtblickdr.e. ist ein Lichtblickdr.e. ist ein Lichtblick
dr.e. eine Nachricht über Skype™ schicken
Standard

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.
__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dr.e. ist offline   Mit Zitat antworten
Alt 24.09.2011, 09:30  
Neuer Benutzer
 
Registriert seit: 02.12.2010
Beiträge: 11
PHP-Kenntnisse:
Fortgeschritten
Mr.H befindet sich auf einem aufstrebenden Ast
Mr.H eine Nachricht über Skype™ schicken
Standard

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?
Mr.H ist offline   Mit Zitat antworten
Alt 26.09.2011, 14:01  
Neuer Benutzer
 
Registriert seit: 15.06.2011
Beiträge: 14
PHP-Kenntnisse:
Fortgeschritten
joshiausdemall befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von dr.e. Beitrag anzeigen
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()).

Geändert von joshiausdemall (26.09.2011 um 14:04 Uhr).
joshiausdemall ist offline   Mit Zitat antworten
Alt 27.09.2011, 01:10  
Moderator und Wett-König
 
Benutzerbild von dr.e.
 
Registriert seit: 21.05.2008
Beiträge: 3.657
PHP-Kenntnisse:
Fortgeschritten
dr.e. ist ein Lichtblickdr.e. ist ein Lichtblickdr.e. ist ein Lichtblickdr.e. ist ein Lichtblickdr.e. ist ein Lichtblickdr.e. ist ein Lichtblick
dr.e. eine Nachricht über Skype™ schicken
Standard

Zitat:
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.

Zitat:
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.

Zitat:
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.
__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dr.e. ist offline   Mit Zitat antworten
Antwort


Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an
Gehe zu

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Problem mit Doctrine2 als ORM skelle Datenbanken 12 16.01.2011 11:27

Besucher kamen über folgende Suchanfragen bei Google auf diese Seite
domänenobjekte, doctrine2, doctrine2 pattern, php mapper pattern implementierung, abgrenzung domänenobjekte, modell, entity, domänenobjekt, doctrine2 dto, doctrine 2 dto, doctrine2 transactionen, doctrine2 mapper, doctrine2 ergebnisse, doctrine2 register domain, php doctrine2, domänenobjekt beispiel programmieren, doctrine2 domain object, data mapper zwei domain objekte

Alle Zeitangaben in WEZ +2. Es ist jetzt 01:39 Uhr.




Powered by vBulletin® Version 3.7.2 (Deutsch)
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
Aprilia-Forum, Aquaristik-Forum, Liebeskummer-Forum, Zierfisch-Forum, Geizkragen-Forum