Gästebuch Tutorial

Hier dreht sich alles um die auf der Webseite veröffentlichten Tutorials. // This forum is all about the APF tutorials.
Thalo
Beiträge: 246
Registriert: 10.08.2009, 16:56:52

Gästebuch Tutorial

Beitrag von Thalo » 14.08.2009, 01:44:15

Hi Doc,


Beim planen meiner Modelle wollte ich mich am APF orientieren, jetzt sitze ich leider schon etwas länger an einem Problem.

Zum hinzufügen neuer Einträge hast du in den Domain Objekten Methoden wie "addEntry" oder "addComment". So ähnlich hatte ich das auch geplant. Leider fehlt mir die Idee, wie ich das ganze später persistiere, ohne das ganze Array durchlaufen zu müssen und zu prüfen, ob der Eintrag / das Kommentar bereits exestieren.

Im Tutorial wurde das gänzlich anders gelöst als wie im UML beschrieben. In den Sourcen vom APF fand ich zwar die besagten Methoden, aber nicht wie sie anschließend, möglichst perfomant, persistiert werden... (Fehlt?)

Die Lösung wie sie im Tutorial ist:
$guestbook->getEntries();
$guestbookManager->addEntry();

finde ich wenig intuitiv.. Kann mich damit nicht so recht anfreunden.

Begründung:
Für jede Eigenschaft gibt es eine getter/setter Methode. Selbst für Entries und Comments gibt es einen getter. Einzig der setter befindet sich im Manager.


Eine bessere Lösung fällt mir allerdings auch nicht ein. Daher wende ich mich dich :)

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

Re: Gästebuch Tutorial

Beitrag von dr.e. » 14.08.2009, 09:34:05

Hallo Thalo,

vorneweg: das Gästebuch-Tutorial ist eines der ältesten auf der Seite. In der Zwischenzeit hat sich einiges verändert, der Text ist jedoch weitestgehend stabil geblieben. Diesem Umstand trage ich insofern Rechnung, als dass ich gerade an einem neuen Artikel für das neue Gästebuch schreibe, dieses aber heute noch nicht auf der Seite verfügbar ist. Die Grundzüge des Tutorials und die Software-technischen Ideen werden jedoch die gleichen bleiben. Insofern kannst du dich natürlich daran orientieren.
Zum hinzufügen neuer Einträge hast du in den Domain Objekten Methoden wie "addEntry" oder "addComment". So ähnlich hatte ich das auch geplant. Leider fehlt mir die Idee, wie ich das ganze später persistiere, ohne das ganze Array durchlaufen zu müssen und zu prüfen, ob der Eintrag / das Kommentar bereits exestieren.
Um dir das Entwickeln zu vereinfachen, würde ich an deiner Stelle einfach den GenericORMapper einsetzen. Dieser kann dir die komplette Arbeit einer Daten- und Persistenz-Schicht abnehmen. Möchtest du das generische Domänen-Objekt nochmals in ein Anwendungs-Domänen-Objekt mappen, dann schreibe einfach eine Datenschicht, die quasi nur noch die Anwendungs-Objekte in GenericDomainObject's mappt. Ein Beispiel kannst du unter http://adventurephpfra.svn.sourceforge. ... iew=markup sehen.
Die Lösung wie sie im Tutorial ist:
$guestbook->getEntries();
$guestbookManager->addEntry();
finde ich wenig intuitiv.. Kann mich damit nicht so recht anfreunden.
Begründung:
Für jede Eigenschaft gibt es eine getter/setter Methode. Selbst für Entries und Comments gibt es einen getter. Einzig der setter befindet sich im Manager.
Die Variablen beinhalten unterschiedliche Typen. $guestbook ist eine Instanz des Gästebuch-Domänen-Objekts und $guestbookManager stellt die Business-Komponente der Anwendung dar. Zwischen Schichten einer Anwendung sollten immer Domänen-Objekte zur Kommunikation eingesetzt werden, weshalb die Methode addEntry() dazu dient, der Business-Schicht ein Domänen-Objekt des Typs Guestbook zu übergeben um dieses zum Gästebuch hinzuzufügen. Meiner Ansicht nach ist das auch heute noch konsequent. :)

Viele Grüße,
Christian
Viele Grüße,
Christian

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

Re: Gästebuch Tutorial

Beitrag von Thalo » 15.08.2009, 18:45:22

Hi Doc,

vielen lieben Dank für deine Antwort. Ich glaube du hast mich da ein wenig missinterpretiert.
dr.e. hat geschrieben: Möchtest du das generische Domänen-Objekt nochmals in ein Anwendungs-Domänen-Objekt mappen, dann schreibe einfach eine Datenschicht, die quasi nur noch die Anwendungs-Objekte in GenericDomainObject's mappt.
Für mich sind Domänen-Objekte immer Anwendungsspezifisch. Wie genau sieht für dich ein generisches Domänen-Objekt aus?

Beispiel:

Anwendung #1 - Social Network
Großes Profil

Benutzername,
Sternzeichen,
Alter,
Gewicht,
Herkunft,
...

Anwendung #2 - Forum
Dürftiges Profil

Benutzername,
Fähigkeiten,
Signatur


Eine weitere Fragen die sich dazu stellt, du hast Methoden wie "getObjektByTextStatement($veryLongSQLQuery)" bindet das nicht an eine SQL fähige Datenquellen?
dr.e. hat geschrieben: Die Variablen beinhalten unterschiedliche Typen. $guestbook ist eine Instanz des Gästebuch-Domänen-Objekts und $guestbookManager stellt die Business-Komponente der Anwendung dar. Zwischen Schichten einer Anwendung sollten immer Domänen-Objekte zur Kommunikation eingesetzt werden, weshalb die Methode addEntry() dazu dient, der Business-Schicht ein Domänen-Objekt des Typs Guestbook zu übergeben um dieses zum Gästebuch hinzuzufügen. Meiner Ansicht nach ist das auch heute noch konsequent. :)
Das ist mir bewusst. Trotzdem stört es mich etwas, mit zwei unterschiedlichen Objekten arbeiten zu müssen. Stichwort: "Dont make me thing"
Vielleicht sehe ich das etwas zu eng. Aber mir würde eine einheitliche Schnittstelle wesentlich besser gefallen.

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

Re: Gästebuch Tutorial

Beitrag von dr.e. » 17.08.2009, 08:13:03

Hallo Thalo,
Für mich sind Domänen-Objekte immer Anwendungsspezifisch. Wie genau sieht für dich ein generisches Domänen-Objekt aus?
Das ist korrekt, Domänen-Objekte sind auch Domänen-(=Anwendungs-)spezifisch. Daran ändert sich auch nichts, wenn du den GenericORMapper verwendest. Es ändert sich dabei lediglich die Idee, wie du diese behandelts. In ausformuliertem Code würdest du für jedes Domain-Object eine eigene Klasse mit den entsprechenden Gettern und Settern schreiben und diese in deiner Anwendung inkl. der Datenschicht verwenden. Beim GORM ist die Idee umgekehrt: du verwendest für alle Objekte dieselbe Klasse und konfigurierst dir deine Anwendungsspezifischen Objekte in einer Konfiguration - der GORM-Konfiguration. Damit kannst du weiter mit den entsprechenden Objekten deiner Anwendung umgehen, sparst dir aber einiges an Implementierungs-Aufwand.
Anwendung #1 - Social Network
Großes Profil
...
Anwendung #2 - Forum
Dürftiges Profil
Was ist für dich ein großes und ein dürftiges Profil? Sollten die beiden Anwendungen etwa die gleiche Code-Basis verwenden, würde ich die Arten der Profile an die Rolle knüpfen und die Datenschicht identisch halten. Falls nicht, kann man sich überlegen, was man tut.
Eine weitere Fragen die sich dazu stellt, du hast Methoden wie "getObjektByTextStatement($veryLongSQLQuery)" bindet das nicht an eine SQL fähige Datenquellen?
Definitiv. Alles andere soll auch zunächst nicht unterstützt werden. Sicher gibt es Datenhaltungs-Möglichkeiten wie CouchDB oder Caché, jedoch sind diese nicht Fokus dieser Implementierung. Ich persönlich halte noch nicht so viel von den genannten Technologien, vielleicht hat ja jemand die Muße einen generischen ORM darauf zu implementieren. :geek:
Das ist mir bewusst. Trotzdem stört es mich etwas, mit zwei unterschiedlichen Objekten arbeiten zu müssen. Stichwort: "Dont make me thing" Vielleicht sehe ich das etwas zu eng. Aber mir würde eine einheitliche Schnittstelle wesentlich besser gefallen.
Das ist Konzept! Hier werden die 3-tier architecture und domain object pattern miteinander kombiniert (cooperation of pattern). Daraus ergibt sich zwangsläufig eine solche Struktur. Gefällt dir das nicht, kannst du auch "intelligente" Domänen-Objekte schaffen, die sich selbst speichern können. Das wiederum ist für meinen Geschmack nicht korrekt, da wir uns da sehr schnell der uncle bob-Technologie nähern und wieder in die Steinzeit der Entwicklung zurückkehren. ;-) Wenn es dir um einheitliche Schnittstellen geht, dann nutze immer Domänen-Objekte als Kommunikations-Medium zwischen Schichten, besser kannst du es nicht implementieren.

Ich denke, für dich dürfte das Buch "Patterns of enterprise applicatin architecture" von Martin Fowler interessant sein. Dort stehen diese Themen nochmal mit Beispielen aufbereitet zum Nachlesen bereit.

Viele Grüße,
Christian

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

Re: Gästebuch Tutorial

Beitrag von Thalo » 22.08.2009, 18:09:34

dr.e. hat geschrieben:
Das ist mir bewusst. Trotzdem stört es mich etwas, mit zwei unterschiedlichen Objekten arbeiten zu müssen. Stichwort: "Dont make me thing" Vielleicht sehe ich das etwas zu eng. Aber mir würde eine einheitliche Schnittstelle wesentlich besser gefallen.
Das ist Konzept! Hier werden die 3-tier architecture und domain object pattern miteinander kombiniert (cooperation of pattern). Daraus ergibt sich zwangsläufig eine solche Struktur. Gefällt dir das nicht, kannst du auch "intelligente" Domänen-Objekte schaffen, die sich selbst speichern können. Das wiederum ist für meinen Geschmack nicht korrekt, da wir uns da sehr schnell der uncle bob-Technologie nähern und wieder in die Steinzeit der Entwicklung zurückkehren. ;-) Wenn es dir um einheitliche Schnittstellen geht, dann nutze immer Domänen-Objekte als Kommunikations-Medium zwischen Schichten, besser kannst du es nicht implementieren.

Ich denke, für dich dürfte das Buch "Patterns of enterprise applicatin architecture" von Martin Fowler interessant sein. Dort stehen diese Themen nochmal mit Beispielen aufbereitet zum Nachlesen bereit.
Hi Doc,

Danke für deine Mühen und deinen langen Atem... ;)

Ich werde mir das Buch besorgen.
Habe mich aber etwas in meinen bereits vorhandenen Büchern gestöbert und bin auf das "Fassde"-Entwurfsmuster gestoßen. Ist dies nicht für meinen Fall das richtige?

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

Re: Gästebuch Tutorial

Beitrag von dr.e. » 22.08.2009, 18:34:00

Hi Thalo,
Danke für deine Mühen und deinen langen Atem... ;)
Kein Problem, dafür bin ich da!
Habe mich aber etwas in meinen bereits vorhandenen Büchern gestöbert und bin auf das "Fassde"-Entwurfsmuster gestoßen. Ist dies nicht für meinen Fall das richtige?
Das könnte sinnvoll sein. Man könnte auch auf das Proxy-Pattern setzen, da du ja auf ein Objekt einer erweiterten Applikation zugreifen möchtest.

Wenn du weitere Fragen - auch zum Thema Pattern - hast, dann können wir hier gerne darüber diskutieren.
Viele Grüße,
Christian

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

Re: Gästebuch Tutorial

Beitrag von Thalo » 22.08.2009, 20:50:19

dr.e. hat geschrieben:
Habe mich aber etwas in meinen bereits vorhandenen Büchern gestöbert und bin auf das "Fassde"-Entwurfsmuster gestoßen. Ist dies nicht für meinen Fall das richtige?
Das könnte sinnvoll sein. Man könnte auch auf das Proxy-Pattern setzen, da du ja auf ein Objekt einer erweiterten Applikation zugreifen möchtest.

Wenn du weitere Fragen - auch zum Thema Pattern - hast, dann können wir hier gerne darüber diskutieren.
Hi Doc,

Ich habe für für das "Facade" - Entwurfsmuster entschieden. Einfach weil es meiner Meinung nach dem am ehesten kommt was ich vor habe.

So sicher wie ich das umsetze weiß ich allerdings nicht. Das Gästebuch soll bleiben wie es ist. Also muss die Facade auch Zugriff auf jeweiliges Domänen-Objekt (Gästebuch, Eintrag, Kommentar) zugreifen. Ist das soweit richtig? Wie realisiere ich so ein Vorhaben am ehesten? Hast du vielleicht auch hier noch einen Tipp für mich?

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

Re: Gästebuch Tutorial

Beitrag von dr.e. » 22.08.2009, 21:26:25

Hi,

kannst du nochmal den Context deines Vorhabens ein wenig näher erläutern. Ich habe das Gefühl, dass wir in unterschiedliche Richtungen argumentieren. Ich möchte einfach vermeiden, dass wir uns missverstehen. :)

Ich fasse mal für mich zu sammen:
Soweit ich dich verstanden habe, möchtest du die Objekte des GenericORMapper - bzw. jeder beliebigen Datenquelle - gegen deine Anwendung - in diesem Fall das Gästebuch - abstrahieren. In diesem Fall reicht es jedoch, wenn du einen zusätzlichen Mapper schreibst und diesem per dependency injection (siehe http://adventure-php-framework.org/Seit ... viceObject) gegen deine Anwendung abstrahierst. Die Schnittstelle des Mappers wird jeweils mit Domänen-Objekten bedient und die Methoden liefern ebenso Domänen-Objekte zurück. Damit kannst du die Datenschicht jederzeit gegen eine MOCK-Schicht austauschen oder die Datenquelle von MySQL auf ORACLE (oder was auch immer) umstellen. Damit ist dein Mapper quasi eine Facade oder ein Proxy auf die Datenquelle.

Korrekt? :P
Viele Grüße,
Christian

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

Re: Gästebuch Tutorial

Beitrag von Thalo » 22.08.2009, 22:02:00

dr.e. hat geschrieben:Hi,

kannst du nochmal den Context deines Vorhabens ein wenig näher erläutern. Ich habe das Gefühl, dass wir in unterschiedliche Richtungen argumentieren. Ich möchte einfach vermeiden, dass wir uns missverstehen. :)

Ich fasse mal für mich zu sammen:
Soweit ich dich verstanden habe, möchtest du die Objekte des GenericORMapper - bzw. jeder beliebigen Datenquelle - gegen deine Anwendung - in diesem Fall das Gästebuch - abstrahieren. In diesem Fall reicht es jedoch, wenn du einen zusätzlichen Mapper schreibst und diesem per dependency injection (siehe http://adventure-php-framework.org/Seit ... viceObject) gegen deine Anwendung abstrahierst. Die Schnittstelle des Mappers wird jeweils mit Domänen-Objekten bedient und die Methoden liefern ebenso Domänen-Objekte zurück. Damit kannst du die Datenschicht jederzeit gegen eine MOCK-Schicht austauschen oder die Datenquelle von MySQL auf ORACLE (oder was auch immer) umstellen. Damit ist dein Mapper quasi eine Facade oder ein Proxy auf die Datenquelle.

Korrekt? :P
Hi Doc,

leider nicht ganz...

Ich möchte es an einem Beispiel näher erläutern:

Momentan ist der guestbookManager für Kommentare, Gästebücher und Einträge zuständig. Das missfällt mir ein wenig. Der guestbookManager ist also zuständig für

- hinzufügen von Gästebüchern
- löschen von Gästebüchern
- löschen von Kommentaren
- hinzufügen von Kommentaren
- löschen von Einträgen
- hinzufügen von Einträgen
- ...

Mir würde es besser gefallen wenn das Gästebuch seine Einträge verwaltet und die Einträge ihre Kommentare. Hier wären wir aber wieder bei den geächteten "Intelligenten" Objekten. Um dies zu vermeiden, dachte ich ich nutze eine Fassade. Damit ich Schnittstellen auf einzelne "Manager" habe.

Ich dachte es mir so:

Der GuestbookManager verwaltet die Gästebücher
Die Gästebücher verwalten ihre Einträge
Die Einträge verwalten ihre Kommentare

so wäre das für mich ein wenig logischer gegliedert. Und etwas näher als der "Realen Welt". Bin ich total auf dem Holzweg? Macht man das in der Softwareentwicklung überhaupt so?

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

Re: Gästebuch Tutorial

Beitrag von dr.e. » 22.08.2009, 22:21:30

Hi,

OK, jetzt bin ich im Bilde. :)
Mir würde es besser gefallen wenn das Gästebuch seine Einträge verwaltet und die Einträge ihre Kommentare. Hier wären wir aber wieder bei den geächteten "Intelligenten" Objekten. Um dies zu vermeiden, dachte ich ich nutze eine Fassade. Damit ich Schnittstellen auf einzelne "Manager" habe.
Das kannst du gerne so implementieren. Dabei ist jedoch wichtig, dass die Intelligenz in den Managern liegt und nicht in den Domänen-Objekten. Dann wäre in einem Controller folgendes denkbar:

Code: Alles auswählen

$id = 1;
$guestbook = Guestbook::getInstance($id);
$entries = $guestbook->getEntries();
Ich habe hier ein getInstance() verwendet um zu demonstrieren, dass das Gästebuch irgendwie konstruiert werden muss. Natürlich möglichst so, dass der Controller nicht wissen muss, wie das geht. Man könnte natürlich wieder eine Fabric einführen, das setzt jedoch voraus, dass der Controller wissen muss, welche Fabric er für was braucht... Alles also irgendwie unschön. Besser wäre meiner Ansicht nach, das Guestbook-Objekt mit dem Service-Manager zu beziehen. So kannst du die Logik der Initialisierung auslagern und musst dich gleichzeitig nicht mehr um allzuviel kümmern. Das würde dann im Controller so funktionieren:

Code: Alles auswählen

$guestbook = $this->__getDIServiceObject('modules::guestbook::biz','Guestbook');
$guestbook->getEntries();
Die Konfiguration des Service-Objekts könnte dann die Initialisierung wie folgt übernehmen:
[Guestbook]
servicetype = "SINGLETON"
namespace = "modules::guestbook::biz"
class = "Guestbook"
init.mgr.method = "setGuestbookManager"
init.mgr.namespace = "modules::guestbook::biz"
init.mgr.name = "GuestbookManager"
conf.id.method = "setGuestbookId"
conf.id.value = "1"

[GuestbookManager]
servicetype = "SINGLETON"
namespace = "modules::guestbook::biz"
class = "GuestbookManager"
Sofern du die Id des Gästebuchs auch dynamisch initialisieren möchtest, würde sich anbieten, diese direkt im Manager aus einem Model auszulesen und dort zu speichern.
Der GuestbookManager verwaltet die Gästebücher
Die Gästebücher verwalten ihre Einträge
Die Einträge verwalten ihre Kommentare

so wäre das für mich ein wenig logischer gegliedert. Und etwas näher als der "Realen Welt". Bin ich total auf dem Holzweg? Macht man das in der Softwareentwicklung überhaupt so?
Das ist schon möglich, nur in sich nicht konsequent. Du müsstest dann für jeden Objekt-Typ einen eigenen Manager haben, da ein Eintrag ja irgendwie an seine Daten kommen muss. Hier würde es sich dann mehr schicken, die Logik doch in den Objekten zu verstecken und diese mit der Instanz der Datenschicht-Komponente zu initialisieren (Mapper). Denn sonst skalieren die Manager mit der Anzahl der Domänen-Objekten und das ist IMHO nicht sinnvoll.

Ich schlage vor, du implementierst dein Gästebuch mal nach deinen Vorstellungen zu Ende und dann schauen wir uns das mal zusammen an. Ich denke während der Entwicklung werden dir einige Dinge auffallen, die sich als Konsequenzen unserer Diskussion ergeben. Diese können wir dann wieder diskutieren und überlegen, was nun besser/einfacher gewesen wäre. Einverstanden?
Viele Grüße,
Christian

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

Re: Gästebuch Tutorial

Beitrag von Thalo » 22.08.2009, 23:00:54

Hi Doc,
dr.e. hat geschrieben:
Der GuestbookManager verwaltet die Gästebücher
Die Gästebücher verwalten ihre Einträge
Die Einträge verwalten ihre Kommentare

so wäre das für mich ein wenig logischer gegliedert. Und etwas näher als der "Realen Welt". Bin ich total auf dem Holzweg? Macht man das in der Softwareentwicklung überhaupt so?
Das ist schon möglich, nur in sich nicht konsequent. Du müsstest dann für jeden Objekt-Typ einen eigenen Manager haben, da ein Eintrag ja irgendwie an seine Daten kommen muss. Hier würde es sich dann mehr schicken, die Logik doch in den Objekten zu verstecken und diese mit der Instanz der Datenschicht-Komponente zu initialisieren (Mapper). Denn sonst skalieren die Manager mit der Anzahl der Domänen-Objekten und das ist IMHO nicht sinnvoll.
Auf die Idee mit den Managern bin ich auch schon gekommen. Meine Befürchtung war allerdings, dass ich zu schnell den Überblick verliere und sich der Quelltext unnötig aufbläht.
dr.e. hat geschrieben: Hier würde es sich dann mehr schicken, die Logik doch in den Objekten zu verstecken und diese mit der Instanz der Datenschicht-Komponente zu initialisieren (Mapper).
Meinst du das Domänen Objekt?
dr.e. hat geschrieben: Ich schlage vor, du implementierst dein Gästebuch mal nach deinen Vorstellungen zu Ende und dann schauen wir uns das mal zusammen an. Ich denke während der Entwicklung werden dir einige Dinge auffallen, die sich als Konsequenzen unserer Diskussion ergeben. Diese können wir dann wieder diskutieren und überlegen, was nun besser/einfacher gewesen wäre. Einverstanden?
Das ist wohl die sinnvollste Lösung. Warscheinlich werde ich aber deine Lösung adaptieren, da ich nun schon beim Modellieren so meine Probleme habe... :?

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

Re: Gästebuch Tutorial

Beitrag von dr.e. » 23.08.2009, 10:48:56

Hallo Thalo,
Meinst du das Domänen Objekt?
Ja. Quasi ein direktes data binding der Domänen-Objekte.
Das ist wohl die sinnvollste Lösung. Warscheinlich werde ich aber deine Lösung adaptieren, da ich nun schon beim Modellieren so meine Probleme habe... :?
OK, ich freue mich auf Ergebnisse, denn ich schreibe gerade am Artikel für das neue Gästebuch. :)
Viele Grüße,
Christian

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

Re: Gästebuch Tutorial

Beitrag von Thalo » 26.08.2009, 16:52:00

Hi Doc,

Habe nun dein Gästebuch so weit adaptiert.

Nun überlege wie ich das Gästebuch (oder andere Komponente) dem User zuteile. Damit das Gästebuch nicht von einem User abhängig ist, dachte ich ich behalte dein Datenbank-Design bei und erweitere es um eine guestbook2user Kompositon. So ist das Gästebuch weiterhin eigenständig und funktional nicht vom User abhängig.

Eine Methode "getGuestbookByUser($user)" würde ich dann via extends erweitern um den Kern später ohne Probleme auszutauschen. Da das Gästebuch ja auch in anderen Projekten seinen einsatz finden soll.

In der Gästebuchtabelle wäre dann allerdings nur eine Spalte "guestbookId"



Was sagst du dazu?

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

Re: Gästebuch Tutorial

Beitrag von dr.e. » 26.08.2009, 23:40:49

Hallo Thalo,

sorry für meine späte Antwort, heute war einiges los. :)
Nun überlege wie ich das Gästebuch (oder andere Komponente) dem User zuteile. Damit das Gästebuch nicht von einem User abhängig ist, dachte ich ich behalte dein Datenbank-Design bei und erweitere es um eine guestbook2user Kompositon. So ist das Gästebuch weiterhin eigenständig und funktional nicht vom User abhängig.
Nicht ganz. Sobald du eine Komposition als Beziehungs-Typ wählst, drückt das eine starke Abhängigkeit aus. Das Gästebuch kann ohne den Benutzer nicht existieren. Weiterhin musst du dich Fragen, ob die Beziehung auch im täglichen Leben so stark ist. Ich denke nicht, denn im realen Leben kann ich ein Gästebuch eröffnen und es später an dich weitergeben. Auch kann es existieren, wenn ein Besitzer (=Benutzer) nicht vorhanden ist. Deshalb würde ich dazu tendieren, eine Assoziation zu verwenden.

Sollte es natürlich in deiner Applikation notwendig sein, dass ich als Benutzer registriert sein muss und dann mein Gästebuch eröffnen kann, sollte eine Komposition richtig sein.
Eine Methode "getGuestbookByUser($user)" würde ich dann via extends erweitern um den Kern später ohne Probleme auszutauschen. Da das Gästebuch ja auch in anderen Projekten seinen einsatz finden soll.
Vererbung ist an dieser Stelle mit Vorsicht zu genießen. Ein weiser Mann sagte mir mal: "Die Komposition ist der Vererbung stehts vorzuziehen!". Das bedeutet in diesem Fall, dass deine Komponente das Gästebuch besser verwenden, statt davon ableiten sollte. So kannst du nach Aussen eine konstante API garantieren und musst bei Änderungen des Gästebuchs nur darauf intern reagieren.
In der Gästebuchtabelle wäre dann allerdings nur eine Spalte "guestbookId"
Das beim Gästebuch und auch beim GORM gewählte Daten-Layout geht davon aus, dass Objekte und Beziehungen jeweils in einer eigenen Tabelle gespeichert werden. Damit ist es völlig ausreichend den Primär-Schlüssel GuestbookId in der Tabelle guestbook zu speichern. Die Referenz wird dann über eine zweite Tabelle mit dem Schlüssel der guestbook-Tabelle und der user-Tabelle hergestellt. Über einen zweifaches JOIN kannst du dann die Beziehung zwischen Benutzer und Gästebuch auflösen. Mit dem GORM ist das übrigens ein Kinderspiel, hier würdest du zum Laden des Gästebuchs / der Gästebücher eines Benutzers folgendes schreiben:

Code: Alles auswählen

$user = $orm->loadObjectByID('User',1);
$gb = $user->loadRelatedObjects('User2Guestbook');
Ich hoffe, das hilft dir weiter.
Viele Grüße,
Christian

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

Re: Gästebuch Tutorial

Beitrag von Thalo » 27.08.2009, 16:11:38

Hi Doc,
dr.e. hat geschrieben:sorry für meine späte Antwort, heute war einiges los. :)
Du musst dich für nichts entschuldigen :)
dr.e. hat geschrieben:
Nun überlege wie ich das Gästebuch (oder andere Komponente) dem User zuteile. Damit das Gästebuch nicht von einem User abhängig ist, dachte ich ich behalte dein Datenbank-Design bei und erweitere es um eine guestbook2user Kompositon. So ist das Gästebuch weiterhin eigenständig und funktional nicht vom User abhängig.
Nicht ganz. Sobald du eine Komposition als Beziehungs-Typ wählst, drückt das eine starke Abhängigkeit aus. Das Gästebuch kann ohne den Benutzer nicht existieren. Weiterhin musst du dich Fragen, ob die Beziehung auch im täglichen Leben so stark ist. Ich denke nicht, denn im realen Leben kann ich ein Gästebuch eröffnen und es später an dich weitergeben. Auch kann es existieren, wenn ein Besitzer (=Benutzer) nicht vorhanden ist. Deshalb würde ich dazu tendieren, eine Assoziation zu verwenden.

Sollte es natürlich in deiner Applikation notwendig sein, dass ich als Benutzer registriert sein muss und dann mein Gästebuch eröffnen kann, sollte eine Komposition richtig sein.
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)?
dr.e. hat geschrieben:
Eine Methode "getGuestbookByUser($user)" würde ich dann via extends erweitern um den Kern später ohne Probleme auszutauschen. Da das Gästebuch ja auch in anderen Projekten seinen einsatz finden soll.
Vererbung ist an dieser Stelle mit Vorsicht zu genießen. Ein weiser Mann sagte mir mal: "Die Komposition ist der Vererbung stehts vorzuziehen!". Das bedeutet in diesem Fall, dass deine Komponente das Gästebuch besser verwenden, statt davon ableiten sollte. So kannst du nach Aussen eine konstante API garantieren und musst bei Änderungen des Gästebuchs nur darauf intern reagieren.
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))?


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.

Da ich ziemlich belesen bin verdienst du dann automatisch daran mit - als kleines Dankeschön für deine Bemühungen ;)

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast