Gästebuch Tutorial

Hier dreht sich alles um die auf der Webseite veröffentlichten Tutorials. // This forum is all about the APF tutorials.
Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 27.08.2009, 21:08:27

Hallo Thalo,
So war es gedacht. Was mir allerdings noch nicht ganz klar ist. Wie sieht der Unterschied einer Komposition und Assoziation auf OOP übertragen aus?

class eins {
$two = new two();
}

ist das eine Komposition (eins hat zwei)?
Der gezeigte Code ist quasi eine Komposition. Da du die Komponenten two innerhalb von eins nutzt, spricht man von einem delegate. Komposition verwendet man mehr bei Datenstrukturen. Die Komposition bezeichnet eine starke Zugehörigkeit (Beispiel: Gästebuch hat Einträge). Jedes Objekt darf nur einmal komponiert werden, da ein reelles Objekt nur exakt eine starke Zugehörigkeit besitzen kann. Die Assoziation dagegen bezeichnet eine schwache Zugehörigkeit. Diese wird verwendet, um für eine Applikation logisch zusammen gehörende Objekte zu verbinden. Assoziationen können jederzeit aufgelöst werden, da das betroffene Objekt weiterhin „lebt“.

In Code ausgedrückt ist eine Komposition folgendes:

Code: Alles auswählen

class one {
   private two;
   public setTwo($two){
      $this->two = $two;
   }
}

class two {
}

$one = new one();
$one->setTwo(new two());
Zusammenfassend bedeutet dies für mich also, der User weiß wie er an sein Gästebuch kommt ($user->getGuestbook()) das Gästebuch aber nicht (getGuestbookByUser($user))?
Genau, da die Beziehung von Benutzer initiiert wird.
Das genannte Buch von Martin Flower ist heute mit DHL gekommen ;)
Habe leider vergessen dich zu fragen ob du einen Amazon-Ref Link hast. Falls ja dann kannst du ihn mir ja schicken.
Fein. Einen RefLink habe ich nicht, Buch-Empfehlungen habe ich nur unter http://adventure-php-framework.org/Seite/037-Literatur.
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 27.08.2009, 23:49:03

Hi Doc,
dr.e. hat geschrieben: In Code ausgedrückt ist eine Komposition folgendes:

Code: Alles auswählen

class one {
   private two;
   public setTwo($two){
      $this->two = $two;
   }
}

class two {
}

$one = new one();
$one->setTwo(new two());
Und wie sieht eine Assoziation aus?

dr.e. hat geschrieben: Fein. Einen RefLink habe ich nicht, Buch-Empfehlungen habe ich nur unter http://adventure-php-framework.org/Seite/037-Literatur.
Davon profitierst du ja nicht. Dachte, dass du wenigstens die Prozente bekommst - als kleines dankeschön ;)

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 28.08.2009, 07:52:16

Hallo Thalo,
Und wie sieht eine Assoziation aus?
Genauso. Unterschied ist hier, dass diese in der Datenschicht anders behandelt wird. Bei einer Komposition kannst du das Objekt one nicht einfach löschen, ohne auch two zu löschen (=abhängige Objekte). Bei einer Assoziation ist das kein Problem. two besteht nach dem Löschen von one einfach weiter. Schau dir dazu mal die GenericORRelationMapper.php um Zeile 713 an. Dort siehst du, wie das Löschen von Objekten behandelt wird, wenn eine Kompositionsbeziehung zu diesem ausgeprägt wird oder dieses Kompositionen ausbildet.
Davon profitierst du ja nicht. Dachte, dass du wenigstens die Prozente bekommst - als kleines dankeschön
Das macht nichts. Kannst mir ja dein fertiges Projekt als Referenz für das APF zur Verfügung stellen, das hilft schon sehr.
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 28.08.2009, 17:23:37

Hi Doc,
dr.e. hat geschrieben:
Und wie sieht eine Assoziation aus?
Genauso. Unterschied ist hier, dass diese in der Datenschicht anders behandelt wird. Bei einer Komposition kannst du das Objekt one nicht einfach löschen, ohne auch two zu löschen (=abhängige Objekte). Bei einer Assoziation ist das kein Problem. two besteht nach dem Löschen von one einfach weiter. Schau dir dazu mal die GenericORRelationMapper.php um Zeile 713 an. Dort siehst du, wie das Löschen von Objekten behandelt wird, wenn eine Kompositionsbeziehung zu diesem ausgeprägt wird oder dieses Kompositionen ausbildet.
Das erklärt auch warum ich nie ein Beispiel dazu gefunden habe :lol:
dr.e. hat geschrieben:
Davon profitierst du ja nicht. Dachte, dass du wenigstens die Prozente bekommst - als kleines dankeschön
Das macht nichts. Kannst mir ja dein fertiges Projekt als Referenz für das APF zur Verfügung stellen, das hilft schon sehr.
[/quote]

Das ist kein Problem. Ist das mindeste was ich tun kann :)



Aber ich glaube allmälich ich bin zu dumm für die OOP. Wenn ich das Gästebuch nicht erweitern soll, wer speichert dann die Komposition zwischen Gästebuch und dem User? :geek:

Was mir auch sorgen bereitet ist, dass der User sein Gästebuch permanent mitschleppt. Spricht etwas dagegen das Gästebuch erst später zu initiieren? (Im User Domänen Objekt selber)

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 28.08.2009, 18:28:10

Hallo Thalo,
Aber ich glaube allmälich ich bin zu dumm für die OOP. Wenn ich das Gästebuch nicht erweitern soll, wer speichert dann die Komposition zwischen Gästebuch und dem User? :geek:
Nein, das glaube ich nicht, es ist nur eine etwas andere Denkweise, an die man sich zunächst gewöhnen muss. Sofern du eine Applikation aus mehreren Bausteinen zusammensetzt, so schickt es sich, für die zusammengesetzte Applikation noch eine weitere Abstraktionsebene einzusetzen. Das bedeutet: wenn das Gästebuch angezeigt und mit Einträgen befüllt wird, tut es seinen Dienst wie auch bisher. Sofern es um die Administration des Gästebuchs geht ebenfalls. Lediglich das Anlegen und Löschen des Gästebuchs ist eine Aufgabe, die dem erweiterten Teil zukommt. Dieser erweiterte Teil muss sich also auch um diese Beziehung kümmern. Sofern du den GenericORMapper nutzt, kannst du diesem dafür die entsprechenden Mapping-Konfigurationen des Gästebuchs mitgeben, dann kann es damit umgehen. In Komponenten gesprochen sollte deine Applikation einen GuestbookBackendManager haben, der sich um die Verbindung zwischen dem fertigen Modul und deiner Anwendung kümmert.
Was mir auch sorgen bereitet ist, dass der User sein Gästebuch permanent mitschleppt. Spricht etwas dagegen das Gästebuch erst später zu initiieren? (Im User Domänen Objekt selber)
Klar. Du kannst die Methode getGuestbook() auch lazy auslegen, sprich erst wenn diese angefragt wird, wird das Gästebuch auch geladen.
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 28.08.2009, 21:46:27

Hi Doc,
dr.e. hat geschrieben:
Sofern du eine Applikation aus mehreren Bausteinen zusammensetzt, so schickt es sich, für die zusammengesetzte Applikation noch eine weitere Abstraktionsebene einzusetzen. Das bedeutet: wenn das Gästebuch angezeigt und mit Einträgen befüllt wird, tut es seinen Dienst wie auch bisher. Sofern es um die Administration des Gästebuchs geht ebenfalls. Lediglich das Anlegen und Löschen des Gästebuchs ist eine Aufgabe, die dem erweiterten Teil zukommt. Dieser erweiterte Teil muss sich also auch um diese Beziehung kümmern. Sofern du den GenericORMapper nutzt, kannst du diesem dafür die entsprechenden Mapping-Konfigurationen des Gästebuchs mitgeben, dann kann es damit umgehen. In Komponenten gesprochen sollte deine Applikation einen GuestbookBackendManager haben, der sich um die Verbindung zwischen dem fertigen Modul und deiner Anwendung kümmert.
Wie genau muss ich mit den BackendManager vorstellen? Eine vererbte Klasse vom GuestbookManager?

Ich hatte vor, für dieses Projekt den GORM nicht zu benutzen. Einfach um ein besseres Gefühl dafür zu bekommen. Oder ist das zu naiv?
dr.e. hat geschrieben:
Was mir auch sorgen bereitet ist, dass der User sein Gästebuch permanent mitschleppt. Spricht etwas dagegen das Gästebuch erst später zu initiieren? (Im User Domänen Objekt selber)
Klar. Du kannst die Methode getGuestbook() auch lazy auslegen, sprich erst wenn diese angefragt wird, wird das Gästebuch auch geladen.
[/quote]

Ja, das gefällt mir wesentlich besser. Ich meinte aber eher, ob das zu viel Logik ist für das Domänen Objekt?

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 28.08.2009, 23:16:25

Hallo Thalo,
Wie genau muss ich mit den BackendManager vorstellen? Eine vererbte Klasse vom GuestbookManager?
Nein, der Manager sollte nur das Gästebuch nutzen. Bei der Auslegung kommt es darauf an, wie du die Backend-GUI darstellen möchtest - denn nur da ist der Manager ja interessant. Ich denke da an ein Menü, das dir die Möglichkeit bietet ein Gästebuch anzulegen. Wird das zugehörige Formular abgeschickt, könnte im BackendManager die Methode createGuestbook($user,$guestbook) aufgerufen werden. Diese hätte - verfolgen wir das Gedankenspiel weiter - folgenden Quellcode:

Code: Alles auswählen

public function createGuestbook($user,$guestbook){

   $gbMgr = new GuestbookManager();
   $gbId = $gbMgr->saveGuestbook($guestbook);

   $mapper = new BackendMapper();
   $mapper->createAssociationUser2Guestbook($user->getId(),$gbId);
  
   // do something else

}
Du nutzt also in diesem Fall die Funktionen des GuestbookManager, leitest aber nicht davon ab.
Ich hatte vor, für dieses Projekt den GORM nicht zu benutzen. Einfach um ein besseres Gefühl dafür zu bekommen. Oder ist das zu naiv?
Das ist nicht naiv. Zur Übung ist es auf jeden Fall sinnvoll, das Mapping von Hand zu implementieren. Hinterher siehst du genau, wo es hakt und welche Aufgaben dir der GORM abnehmen kann.
Ja, das gefällt mir wesentlich besser. Ich meinte aber eher, ob das zu viel Logik ist für das Domänen Objekt?
Nein an sich nicht, es werden ja darin keine komplexen Business-Prozesse abgebildet, sondern nur Daten geliefert. Das Domänen-Objekt ist damit quasi ein Proxy, was durchaus zulässig ist.
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 29.08.2009, 03:06:09

Hi Doc,

Nun versteh ich gar nichts mehr :(
dr.e. hat geschrieben:
Wie genau muss ich mit den BackendManager vorstellen? Eine vererbte Klasse vom GuestbookManager?
Nein, der Manager sollte nur das Gästebuch nutzen. Bei der Auslegung kommt es darauf an, wie du die Backend-GUI darstellen möchtest - denn nur da ist der Manager ja interessant. Ich denke da an ein Menü, das dir die Möglichkeit bietet ein Gästebuch anzulegen. Wird das zugehörige Formular abgeschickt, könnte im BackendManager die Methode createGuestbook($user,$guestbook) aufgerufen werden. Diese hätte - verfolgen wir das Gedankenspiel weiter - folgenden Quellcode:

Code: Alles auswählen

public function createGuestbook($user,$guestbook){

   $gbMgr = new GuestbookManager();
   $gbId = $gbMgr->saveGuestbook($guestbook);

   $mapper = new BackendMapper();
   $mapper->createAssociationUser2Guestbook($user->getId(),$gbId);
  
   // do something else

}
Du nutzt also in diesem Fall die Funktionen des GuestbookManager, leitest aber nicht davon ab.
Die Methode saveGuestbook speichert ja jedesmal die kompletten Einträge + Kommentare. Bei etwas größeren Gästebüchern ist das warscheinlich ein ziemlicher Flaschenhals. Oder nicht?

Muss ich dann später mit beiden Managern arbeiten? Wird das nicht ein wenig unübersichtlich? Ich kann mir gar nicht vorstellen, dass sich dadurch der Wartungsauwand verringert bzw ich flexibler werde.

Wenn ich nun das Gästebuche anhand eines Users laden möchte, wer ist dann dafür zuständig? Du sagtest nicht das Gästebuch. Soll ich also den User genauso erweitern wie das Gästebuch auch und eine weitere zwischenschicht hinzufügen? Vielleicht ist es erwähnenswert, dass nebst Gästebuch auch noch ein Blog, Poll, Galerie, ... dazu stoßen.

Was genau spricht denn dagegen, den Manager um einige Methoden zu erweitern anstatt zwei Klassen zu schreiben?


Das zeigt mal wieder perfekt, dass das erlernen einer Sprache in der Softwareentwicklung erst die halbe Miete ist :geek:
Wo lernt man das eigentlich? Bücher sind da nicht wirklich hilfreich bei...

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 29.08.2009, 11:14:26

Hi Thalo,
Nun versteh ich gar nichts mehr :(
Nicht gut. Ich versuche dir deine Fragen einfach mal der Reihe nach zu beantworten...
Die Methode saveGuestbook speichert ja jedesmal die kompletten Einträge + Kommentare. Bei etwas größeren Gästebüchern ist das warscheinlich ein ziemlicher Flaschenhals. Oder nicht?
In der Implementierung des APF-Gästebuchs (beide Versionen) ist das so. Allerdings beschränkt sich das beim Anlegen eines Gästebuchs auf ein Guestbook-Objekt, beim Erstellen eines Eintrags auf ein Entry-Objekt und beim Kommentieren auf ein Entry- + ein Comment-Objekt. Das ist also Performance-technisch unbedenklich. Sofern du wissen möchtest, was da an Statements abgeschickt wird, schalte einfach beim connectionManager den Debug-Modus dein (siehe API-Doku der Methode executeTextStatement() oder executeStatement()).
Muss ich dann später mit beiden Managern arbeiten? Wird das nicht ein wenig unübersichtlich? Ich kann mir gar nicht vorstellen, dass sich dadurch der Wartungsauwand verringert bzw ich flexibler werde.
Die beiden Manager haben im Grunde ihre getrennten Aufgaben. Der BackendManager ist für die Koordination der Backend-Aufgaben zuständig, der GuestbookManager nur für die Anzeige des Gästebuchs auf der Frontend-Seite. Zumindest habe ich deinen Anwendungs-Fall so verstanden. Damit erreichst du eine Kapselung der beiden "Module" und muss lediglich im Backend den GuestbookManager nutzen um einige Aufgaben (wie Anlegen, Bearbeiten und Löschen eines Gästebuchs) zu erfüllen.
Wenn ich nun das Gästebuche anhand eines Users laden möchte, wer ist dann dafür zuständig?
Das scheint mir eine Backend-Aufgabe zu sein, die der BackendManager zu erledigen hat.
Du sagtest nicht das Gästebuch. Soll ich also den User genauso erweitern wie das Gästebuch auch und eine weitere zwischenschicht hinzufügen?
Ich persönlich halte nichts von zu intelligenten Domänen-Objekten, deswegen lade ich meine Domänen-Objekte immer über Business-Komponenten.
Vielleicht ist es erwähnenswert, dass nebst Gästebuch auch noch ein Blog, Poll, Galerie, ... dazu stoßen.
Hmm, das ist natürlich eine etwas andere Geschichte. Du willst also ein komplettes Backend + Fronend schreiben, in dem ein Benutzer diese Elemente anlegen und werwalten kann, richtig? Dann würde ich doch fast den Ansatz eines klassischen Backends wählen: es gibt eine Nutzerverwaltung, die ein Model verwaltet in dem der eingeloggte Benutzer enthalten ist. Dieses steht dann den einzelnen Modulen zur Verfügung und die Manager der einzelnen Module bedienen sich dieser Information. Das kehrt die Verantwortung etwas um, ist aber an sich flexibler, da du nicht - wie oben besprochen - in die einzelnen Module "eingreifen" musst.

Ein Modul hat dabei immer einen Frontend- und einen Backend-Part, welche Views abgezeigt werden, entscheidest du einfach an Hand der Einbindung in Front- und Backend.
Was genau spricht denn dagegen, den Manager um einige Methoden zu erweitern anstatt zwei Klassen zu schreiben?
Mit dem zuletzt beschrieben Ansatz nichts, denn ich denke das ist für deinen Anwendungs-Fall sinnvoller.
Das zeigt mal wieder perfekt, dass das erlernen einer Sprache in der Softwareentwicklung erst die halbe Miete ist :geek:
Wo lernt man das eigentlich? Bücher sind da nicht wirklich hilfreich bei...
Das lernt man leider nicht in der Schule und auch nicht nur durch Lesen von Büchern, hier ist üben, üben, üben angesagt. Und du bist auf einem guten Weg, denn du liest Bücher, stellst Fragen und probierst aus. Kein besseres Rezept habe ich auch nicht, mir ging es genauso. ;)
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 29.08.2009, 17:50:16

Hi Doc,
dr.e. hat geschrieben:Hi Thalo,
Nun versteh ich gar nichts mehr :(
Nicht gut. Ich versuche dir deine Fragen einfach mal der Reihe nach zu beantworten...
Die Methode saveGuestbook speichert ja jedesmal die kompletten Einträge + Kommentare. Bei etwas größeren Gästebüchern ist das warscheinlich ein ziemlicher Flaschenhals. Oder nicht?
In der Implementierung des APF-Gästebuchs (beide Versionen) ist das so. Allerdings beschränkt sich das beim Anlegen eines Gästebuchs auf ein Guestbook-Objekt, beim Erstellen eines Eintrags auf ein Entry-Objekt und beim Kommentieren auf ein Entry- + ein Comment-Objekt. Das ist also Performance-technisch unbedenklich. Sofern du wissen möchtest, was da an Statements abgeschickt wird, schalte einfach beim connectionManager den Debug-Modus dein (siehe API-Doku der Methode executeTextStatement() oder executeStatement()).
So wie ich das dem Source entnehme, wird beim speichern des Gäsebuchs jeder Eintrag durchlaufen und Eintrag + Kommentar gespeichert, inkl der Komposition.
dr.e. hat geschrieben:
Vielleicht ist es erwähnenswert, dass nebst Gästebuch auch noch ein Blog, Poll, Galerie, ... dazu stoßen.
Hmm, das ist natürlich eine etwas andere Geschichte. Du willst also ein komplettes Backend + Fronend schreiben, in dem ein Benutzer diese Elemente anlegen und werwalten kann, richtig? Dann würde ich doch fast den Ansatz eines klassischen Backends wählen: es gibt eine Nutzerverwaltung, die ein Model verwaltet in dem der eingeloggte Benutzer enthalten ist. Dieses steht dann den einzelnen Modulen zur Verfügung und die Manager der einzelnen Module bedienen sich dieser Information. Das kehrt die Verantwortung etwas um, ist aber an sich flexibler, da du nicht - wie oben besprochen - in die einzelnen Module "eingreifen" musst.
Verstehe ich das richtig, dass mein eigentliches Vorhaben richtig war? Also erweitere ich den Manager um die Methoden loadGuestbookByUser, createGuestbookWithComposition, deleteGuestbookWithComposition,...?
dr.e. hat geschrieben:
Was genau spricht denn dagegen, den Manager um einige Methoden zu erweitern anstatt zwei Klassen zu schreiben?
Mit dem zuletzt beschrieben Ansatz nichts, denn ich denke das ist für deinen Anwendungs-Fall sinnvoller.
Mir ist nicht ganz klar, warum nur da. Mir gefällt der Ansatz allgemein ein wenig besser..

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 29.08.2009, 18:02:03

Hi,
So wie ich das dem Source entnehme, wird beim speichern des Gäsebuchs jeder Eintrag durchlaufen und Eintrag + Kommentar gespeichert, inkl der Komposition.
Das ist korrekt. Wenn der Input - sprich der zu speichernde Objektbaum - klein ist, wird auch nur dieser kleine Part gespeichert. Dies sollte ohnehin immer in schreibenden Applikationen versucht werden.
Verstehe ich das richtig, dass mein eigentliches Vorhaben richtig war? Also erweitere ich den Manager um die Methoden loadGuestbookByUser, createGuestbookWithComposition, deleteGuestbookWithComposition,...?
Ja das war/ist es. Ich bin an dieser Stelle von etwas zu eingeschränkten Tatsachen ausgegangen, sorry, wenn ich dadurch mehr verwirrt habe. :roll:
Mir ist nicht ganz klar, warum nur da. Mir gefällt der Ansatz allgemein ein wenig besser..
Mit "dem zuletzt beschrieben Ansatz" meinte ich, die Komponenten zu erweitern. Am besten du nimmst deine Idee und startest mit der Implementierung, dann siehst du schon, wo es haken könnte. Solltest du dazu Fragen haben, dann immer her damit!
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 31.08.2009, 21:51:08

Hi Doc,


Die Nervensäge schon wieder ;)


Im Gästebuch wurden die Daten des Users direkt mit in das Entry Domänen-Objekt gespeichert. Das hielt ich für wenig unflexibel und habe es in ein eigenes User Domänen-Objekt verlegt. Im nachhinein habe ich bemerkt, dass das bei dem neuen Gästebuch genauso gamacht wurde.

Ob ich den User dann anschließend in der gleichen Tabelle speichere wie die Einträge, oder in einer seperaten, bin ich mir noch nicht ganz einst.


Nun bemerke ich aber, dass ich Probleme bekomme an dieser Stelle. Da ich für den User auf den üblichen "Applikation"-User nutze und in einer relation-Tabelle die Beziehung speichere.

Da ich nicht den GORM nutze werde ich die Datenstruktur im Mapper komplett anpassen müssen. Da frage ich mich ob es nicht besser wäre, den Mapper gleich neu zu schreiben?

Wie löst man solche Probleme möglichst elegant?

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 31.08.2009, 23:27:50

Hallo Thalo,
Die Nervensäge schon wieder ;)
Warum? Für Fragen bin ich doch da! :geek:
Im Gästebuch wurden die Daten des Users direkt mit in das Entry Domänen-Objekt gespeichert. Das hielt ich für wenig unflexibel und habe es in ein eigenes User Domänen-Objekt verlegt. Im nachhinein habe ich bemerkt, dass das bei dem neuen Gästebuch genauso gamacht wurde.
Exakt. Das ist eine nur allzu konsequente Weiterentwicklung aus Sicht der Modellierung der Domäne. Gut erkannt!
Ob ich den User dann anschließend in der gleichen Tabelle speichere wie die Einträge, oder in einer seperaten, bin ich mir noch nicht ganz einst.
Die Daten in der gleichen Tabelle zu speichern wäre nicht konsequent. Da es sich hierbei um ein echtes, eigenständiges Objekt handelt, sollte dieses auch als solches behandelt werden.
Nun bemerke ich aber, dass ich Probleme bekomme an dieser Stelle. Da ich für den User auf den üblichen "Applikation"-User nutze und in einer relation-Tabelle die Beziehung speichere. Da ich nicht den GORM nutze werde ich die Datenstruktur im Mapper komplett anpassen müssen. Da frage ich mich ob es nicht besser wäre, den Mapper gleich neu zu schreiben?
Ich würde sagen: Mapper neu schreiben und in Kauf nehmen, dass du dir in den Mapper eine direkte Abhängigkeit einbaust oder dem Mapper einen eigenen UserMapper injizieren (Beispielsweise mit dem DIServiceManager), der genutzt werden kann, das User-Objekt zu speichern und eine Beziehung zwischen Gästebuch und Benutzer herzustellen.
Wie löst man solche Probleme möglichst elegant?
Elegant wäre, pro Applikation einen eigenen Mapper zur Verfügung zu stellen und die Kopplung in der Business-Schicht vorzunehmen, denn dort sollte diese Logik eigentlich verpackt sein. Sofern du einen eigenen Mapper für die Übergreifenden Beziehungen implementierst, kannst du dort sehr einfach das Gästebuch mit Hilfe des GuestbookMapper speichern und eine Beziehung mit dem RelationMapper herstellen.
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 01.09.2009, 12:15:53

Hi Doc,

dr.e. hat geschrieben:
Ob ich den User dann anschließend in der gleichen Tabelle speichere wie die Einträge, oder in einer seperaten, bin ich mir noch nicht ganz einst.
Die Daten in der gleichen Tabelle zu speichern wäre nicht konsequent. Da es sich hierbei um ein echtes, eigenständiges Objekt handelt, sollte dieses auch als solches behandelt werden.
Sehe ich das richtig, dass ich dann eine Vielzahl von "User"-Tabellen habe?


dr.e. hat geschrieben: Elegant wäre, pro Applikation einen eigenen Mapper zur Verfügung zu stellen und die Kopplung in der Business-Schicht vorzunehmen, denn dort sollte diese Logik eigentlich verpackt sein. Sofern du einen eigenen Mapper für die Übergreifenden Beziehungen implementierst, kannst du dort sehr einfach das Gästebuch mit Hilfe des GuestbookMapper speichern und eine Beziehung mit dem RelationMapper herstellen.
Kannst du das etwas näher erläutern? Was genau meinst du mit "die Kopplung in der Business-Schicht"?

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 01.09.2009, 21:10:15

Hallo Thalo,

da du bei der konkreten Applikation nun ohnehin eine Abhängigkeit zum "globalen Modul" Benutzer-Management aufbauen musst (Beziehungen zum Benutzer), kannst du das in den Managern der einzelnen Module so lösen:

Code: Alles auswählen

public function saveGuestbook($gb){
   $user = $userManager->getLoggedInUser();
   $gbId = $gbMapper->saveGuestbook($gb);
   $relationMapper->createAssociation4Guestbook($gbId,$user->getId());
}
Damit hast du die Aufgaben sauber getrennt und kannst die Mapper an beliebigen Stellen wieder verwenden.
Sehe ich das richtig, dass ich dann eine Vielzahl von "User"-Tabellen habe?
Nein, sondern lediglich eine Tabelle, dafür mehrere Tabellen, die die Beziehung zwischen z.B. einem Gästebuch, einem Blog, ... und dem Benutzer herstellen. Über ein INNER JOIN kannst du dann ganz einfach die Inhalte, die ein Benutzer angelegt hat auslesen. Beispiel:
  • Tabelle blog (Speichert einen Blog)
  • Tabelle user (speichert die Benutzer-Daten)
  • Tabelle user2blog (speichert die Beziehung)
Dann kannst du via

Code: Alles auswählen

SELECT * FROM blog
INNER JOIN user2blog on blog.id = user2blog.blogid
INNER JOIN user2blog on user2blog.userid = user.id
WHERE user.id = 123;
bequem die angelegten Blogs eines Nutzers auslesen. Selbiges Konstrukt kannst du auch für alle anderen Objekte nutzen, die eine Beziehung zu einem Benutzer brauchen.
Viele Grüße,
Christian

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast