Ich habe mehrere PHP-Frameworks gelesen, insbesondere das Zend Framework, aber ich bin verwirrt darüber, wie es weitergehen soll.
Zend Framework verwendet keine ActiveRecords, sondern verwendet stattdessen das Table Data Gateway- und Row Data Gateway-Muster und verwendet einen DataMapper, um den Inhalt des Row Data Gateway dem Modell zuzuordnen, da ActiveRecord zusammenbricht, wenn Ihre Modelle nicht vorhanden sind eine 1: 1-Zuordnung zu Ihren Datenbanktabellen. Es gibt ein Beispiel dafür im Zend Quickstart Guide.
Für mich sieht ihr Beispiel sehr aufgebläht aus, mit einer Menge Getter und Setter überall. Ich stieß auf verschiedene Blog-Posts über Domain Driven Design und argumentierte, dass die Verwendung so vieler Getter und Setter schlecht ist, da alle inneren Modelldaten nach außen offen gelegt werden, so dass sie keinen Vorteil gegenüber öffentlichen Attributen haben. Hier ist ein Beispiel .
Meine Frage: Wenn Sie diese Getter und Setter entfernen, wie werden Sie Ihre Ansichten rendern? Irgendwann müssen die Daten die Ansicht treffen, damit Sie dem Benutzer etwas zeigen können. Nach dem DDD-Rat scheint die Trennung zwischen M und V in MVC zu brechen. Nach dem MVC und Zend-Beispiel scheint DDD zu brechen und lässt mich eine ganze Menge Getter, Setter und DataMapper für alle meine Modelle eingeben. Abgesehen davon, dass es eine Menge Arbeit ist, scheint es DRY zu verletzen.
Ich würde wirklich einige (Links zu) gute Beispiele oder mehr Informationen darüber schätzen, wie alles zusammenpasst. Ich versuche hier meine architektonischen und gestalterischen Fähigkeiten zu verbessern.
Mit Value Objects können Sie einige dieser öffentlichen Setter-Methoden eliminieren. Hier ist eine Beschreibung von der Unterschied zwischen Entity und Value Objects . Wertobjekte sind unveränderlich und oft an eine Entität gebunden. Wenn Sie alle Werte mit dem Konstruktor übergeben, müssen Sie diese Eigenschaften nicht über externen Code festlegen.
Etwas extra, nicht direkt auf eine Antwort bezogen, sondern mehr auf DDD konzentriert:
(Disclaimer: Das Einzige, was ich über das Zend Framework weiß, ist das, was ich im verlinkten Artikel gelesen habe.) Das Zend Framework verwendet DataMapper anstelle von Repositories. Ist das wirklich DDD-ish? Nun, Fowlers Interpretation eines Repositories könnte nein sagen. Eric Evans erklärt jedoch, dass ein DDD-Repository sehr einfach sein kann. Im einfachsten Fall ist ein Repository ein DataMapper (siehe DDD-Buch). Für etwas komplexeres und immer noch DDD, siehe den Fowler-Artikel. DDD hat ein konzeptionelles Repository, das sich von der Musterdefinition unterscheiden kann.
Ich fordere Sie auf, weiter über das Domain-Driven Design zu lesen. Ich denke, es gibt einen Fehler in der Annahme, dass Getter und Setter gegen DDD verstoßen. Bei DDD geht es darum, sich auf das Domänenmodell und die Best Practices zu konzentrieren, um dies zu erreichen. Accessoren sind nur ein kleines Detail.
Sie müssen nicht alle Getter / Setter implementieren, Sie können__get () und __set () verwenden. Was ist das Problem dann?
Nach meiner Lektüre des Beitrags ist die Frage eher philosophischer als praktischer Natur.
Ich habe nicht die Zeit, ausführlich zu schreiben, aber hier sind meine zwei Cent. Obwohl ich zustimme, dass Sie die Anzahl der get und set-Anfragen begrenzen wollen, weil eine Klasse ihre Interna verbergen sollte, müssen Sie auch berücksichtigen, dass Java und PHP verschiedene Werkzeuge sind und unterschiedliche Zwecke haben. In der Web-Umgebung werden Ihre Klassen mit jeder Anfrage aufgebaut und abgebaut. Daher sollte der Code, den Sie schreiben, nicht von großen Klassen abhängig sein. In dem Artikel, auf den Sie hingewiesen haben, schlägt der Autor vor, die View-Logik in der Klasse zu platzieren. Dies macht wahrscheinlich keinen Sinn im Web, da ich wahrscheinlich die Ansicht in mehreren Formaten (rss, html, etc ...) präsentieren möchte. Die Verwendung von Zugriffsmethoden (get & amp; set) ist daher ein notwendiges Übel. Sie wollen sie immer noch nachdenklich einsetzen, damit Sie sich nicht in den Fuß schießen. Der Schlüssel ist, zu versuchen, dass Ihre Klassen die Arbeit für Sie erledigen, statt zu versuchen, sie dazu zu zwingen, extern zu arbeiten. Indem Sie auf Ihre Eigenschaften mit einer Methode zugreifen, statt direkt, verbergen Sie die internen Elemente, was Sie wollen.
Noch einmal, dieser Beitrag könnte einige Beispiele verwenden, aber ich habe gerade keine Zeit.
Kann jemand anderes ein paar Beispiele dafür liefern, warum Accessor-Methoden nicht böse sind?
Hier gibt es zwei Ansätze: Was ich den "Sag nicht fragen" -Ansatz nenne, und den anderen ist der ViewModel / DTO-Ansatz. Im Wesentlichen dreht sich die Frage darum, was aus Ihrer Sicht das "Modell" ist. Tell do not ask fordert, dass die einzige Möglichkeit, ein Objekt zu externalisieren, aus dem Objekt selbst stammt. Mit anderen Worten, um ein Objekt zu rendern, müssten Sie eine Rendermethode verwenden, diese Rendermethode müsste jedoch mit einer Schnittstelle kommunizieren. Etwas wie das:
%Vor%Im Kontext von Zend Framework kannst du Zend_View ableiten und deine Unterklasse diese Schnittstelle implementieren lassen.
Ich habe das schon mal gemacht, aber es ist etwas unhandlich.
Die zweite Option besteht darin, Ihr Domänenmodell in ein ViewModel-Objekt zu konvertieren, das einer vereinfachten, vereinfachten Ansicht Ihrer Daten entspricht, die für jede spezifische Ansicht (mit einem ViewModel pro Ansicht) und für jeden View angepasst wurde den Weg zurück, konvertieren Sie die POST-Daten in ein EditModel.
Dies ist ein sehr beliebtes Muster in der ASP.NET MVC-Welt, aber es ähnelt auch dem "DTO" -Klassenmuster, das zum Übertragen von Daten zwischen "Schichten" in einer Anwendung verwendet wird. Sie müssten Mapper erstellen, um die Drecksarbeit für Sie zu erledigen (im Gegensatz zu einem DataMapper). In PHP 5.3 können Sie private Eigenschaften mithilfe von Reflection ändern, sodass Ihr DomainObject sich nicht einmal selbst ausstellen muss!
Die Implementierung von Gettern und Settern hat in meinen Augen zwei Vorteile:
Tags und Links model-view-controller activerecord dry zend-framework domain-driven-design