[OOP] MVC und Performance

**PHP-Desaster** · 30.01.2008, 12:39

Re: [OOP] MVC und Performance

Mittlerweile denke ich dass das ganze übersichtlicher wäre wenn ich alle Actions in einem Modulcontroller habe nur weiss ich eben nicht ob die Übersichtlichkeit den Performanceverlust rechtfertigt, sofern es überhaupt einen gibt.

Der Sinn von MVC liegt ja eher in der Übersichtlichkeit als in der Performance. Außerdem schätze ich den Performanceverlust - wenn überhaupt - sehr gering ein. Pack das lieber in eine Klasse, dann kannst du auch verschiedene Aktionen einfacher miteinander verbinden, indem du entsprechende Methoden aufrufst. Das Einbinden entsprechender Dateien um diese Aktion auszuführen ist da doch etwas unsauberer.

**kaguya** · 30.01.2008, 12:42

da hast du wohl recht, und wenn man sich anguckt was allein Smarty alles einbindet sind die paar Controller Methoden wohl nicht wirklich schlimm.

Wobei ich Smarty in der aktuellen Version auch rauswerfen werde und gegen vlib ersetze.

**PHP-Desaster** · 30.01.2008, 12:54

Ich kenne vlib jetzt nicht, ich würde Smarty aber nicht unbedingt als gutes Beispiel nehmen

Der Grundgedanke bei der OOP entspricht aber generell immer eher der Übersichtlichkeit und Modularisierung. Performance kannst du anschließend einbauen, in dem du beispielsweise entsprechende Daten cachst oder deinen PHP-Code compilierst.

**kaguya** · 30.01.2008, 12:58

ja, mittlerweile sehe ich das auch so. Der Gewinn was Übersichtlichkeit und Wartbarkeit angeht wiegt den Performanceverlust locker auf und da gibt es wie du schon sagst genügend andere Möglichkeiten.

Trotzdem ist Smarty mir mittlerweile zu aufgebläht, auch wenn es die templates compiliert, da ich aber aus bestimmten Gründen unbedingt eine Template Engine einsetzen will habe ich mich für vlib Template entschieden, soll wohl sehr gut sein.

Danke für deine Meinung, dann werde ich das so machen.

**Kropff** · 30.01.2008, 13:02

habe ich mich für vlib Template entschieden

mal an xsl gedacht? ist imho das einzige, dass den namen templatesystem bei php wirklich verdient. alles andere ist in meinen augen nur pseudo.

gruß
peter

**kaguya** · 30.01.2008, 13:07

Original geschrieben von Kropff
mal an xsl gedacht? ist imho das einzige, dass den namen templatesystem bei php wirklich verdient. alles andere ist in meinen augen nur pseudo.

gedacht ja, habe da allerdings 0 praktische Erfahrung, wüsste nichtmal wie so ein "template" dann aussieht und ich denke die Designer die, die Layouts für mich umsetzen auch nicht und genau das ist das Problem.

Ich weiss das eine Template Engine eigentlich unnötig ist, trotzdem ist das erstellen der templates für "nicht Programmierer" immernoch einfacher mit einer template Engine.
Außerdem gibt man dem Designer ohne Template Engine die Möglichkeit die komplette PHP Funktionalität in den templates zu nutzen, was wieder mehr Fehler oder im schlimmsten Fall Sicherheitslücken bedeuten kann.
Aus Erfahrung will ich es den "HTML Leuten" so einfach und simpel machen wie möglich weil ich wenig Lust habe jedes template später nochmal zu bearbeiten weil irgendwas falsch gemacht wurde.

**Hopka** · 30.01.2008, 13:34

Bei MVC muss man sich immer vor Augen halten, dass das Pattern nicht ursprünglich für die Web-Entwicklung geschaffen wurde.
Wenn du also einen Front-Controller in der Form einsetzt, dass er die URL auswertet und dann entscheidet, welche Scripte er lädt, dann hat das natürlich einen kleinen Einfluss auf die Performance, aber man muss auch noch viele weitere Aspekte bedenken (was ist z.B. wenn du mal eine Datei direkt, also nicht über den Front-Controller aufrufen willst?). Im Grunde tut er dann aber nicht viel mehr, als der Web-Server - und der ist auf solche Sachen spezialisiert. Es ist nicht verkehrt, den Web-Server als eine Art Front-Controller einzusetzen. Du hast ja immer noch die Möglichkeit, in bestimmten Ordnern oder Scripten Page-, Action-, oder Modul-Controller (oder wie auch immer du sie nennst) in PHP zu realisieren. Je nach dem was du unter einem Modul verstehst, kann es durchaus Sinn machen, einen Controller pro Modul zu haben oder auch mehrere Controller pro Modul.

Es gibt dabei nicht die eine, richtige Lösung.

Was ich jedoch problematisch finde ist, dass MVC auf die meisten Web-Anwendungen einfach nicht passt. Und wenn man es erst mit irgendwelchen Kunstgriffen passend machen muss, dann behindert das Ganze die Entwicklung mehr, als dass es sie fördert. Und dann sollte man Abstand davon halten.

Man darf bei der Verwendung von Design-Patterns nicht hingehen und sagen "OK, hier habe ich ein Pattern, wo baue ich das bei mir ein?". Wenn man ein Problem lösen will, muss man sich Fragen, welches Pattern darauf passt - und wenn keins passt sollte man auch keins benutzen.

Original geschrieben von Kropff
mal an xsl gedacht? ist imho das einzige, dass den namen templatesystem bei php wirklich verdient. alles andere ist in meinen augen nur pseudo.

Bleibt nur die Frage, ob man mehr Wert auf den Namen oder auf die Benutzbarkeit legt. Und XSL(T) ist glaube ich für die meisten Leute viel zu kompliziert.

P.S.: Ist dieser Thread nicht mehr ein Brainstorming?

**kaguya** · 30.01.2008, 13:43

@hopka

Hm, ich finde das MVC Pattern für Web Anwendungen durchaus geeignet, auch in meinem speziellen Fall denke ich das es die beste Lösung ist was die Architektur angeht.

Irgendeine Art Front-Controller wird ja jeder integriert haben, ob nun bewusst oder unbewusst, OOP oder prozedural, aber irgendwie hat das sicherlich jeder.

Mir ging es einfach nur darum das ich aktuell zb pro Modul ein Verzeichnis habe, darin dann für jede Action einen Controller (Beispiel forum: neuestopic, neueantwort, beitrag löschen etc) und so halt nur der Controller Code eingebunden wird der am Ende auch genutzt wird.

Nur sehe ich es in letzter Zeit öfter das es zb einen ForumController gibt wo alle diese Actions in einer Datei implementiert sind, dh also alle Actions für das aktuelle Modul geladen werden auch wenn nur eine ausgeführt wird.

Performancetechnisch sicherlich nachteilig, meine Frage ob man das überhaupt merkt? Weil die Übersichtlichkeit und Wartbarkeit würde es schon verbessern, nachdem ich jetzt 2 Jahre mit der ersten Variante gearbeitet habe gibt es doch teilweise sehr viele einzelne Dateien wo auch teilweise nur wenige Zeilen Code drinsteht und das ist irgendwann nicht mehr wirklich Übersichtlich.

Aber Propel wird mich vermutlich deutlich mehr Performance kosten als diese Controller Geschichte und da ist es mir auch egal weil der Nutzen überwiegt.

bzgl. Brainstorming, da hast du wohl recht, passt da wohl besser.

**kaguya** · 30.01.2008, 14:00

ich habe noch eine andere MVC Frage die unter anderem mit der Performance zutun hat.

Angenommen ich habe einen UserController wo die methode showProfile implementiert ist um ein Profil anzuzeigen. Dieser Controller instanziiert nun das UserModell das durch Propel generiert wurde und um einige Methoden erweitert wurde.
Ist es nun im Sinne des MVC Patterns dieses Propel UserModel Objekt an die View zu übergeben ? Schliesslich kann ich dann im Template direkt per getXYZ alle Userdaten abrufen die ich in der View brauche.

"Darf" man das so machen oder sollte man dann für den User noch eigene Klassen haben (die aber ja im Prinzip sowieso die gleiche Funktionalität implementieren würden wie das UserModel das Propel schon generiert hat.

Oder ist es generell perfomanetechnisch eine Sünde mit Objekten innerhalb der View zu arbeiten ?

Viele Fragen, aber ich will mich nicht in einem Jahr ärgern das ich etwas falsch gemacht habe

**ModestLife** · 30.01.2008, 22:50

Aber Propel wird mich vermutlich deutlich mehr Performance kosten als diese Controller Geschichte und da ist es mir auch egal weil der Nutzen überwiegt.

Bevor du Propel nimmst, wirf noch nen Blick auf www.phpdoctrine.org. :-)

**kaguya** · 30.01.2008, 23:00

Original geschrieben von ModestLife
Bevor du Propel nimmst, wirf noch nen Blick auf www.phpdoctrine.org. :-)

Habe ich mir auch schon angesehen, Propel 1.3 mit PDO soll aber deutlich schneller sein, sogar schneller als Doctrine.
Bei Doctrine bin ich mir nicht sicher ob da auch die Model Klassen generiert werden oder nur der SQL Code? Da nimmt einem Propel ja schon einiges an Arbeit ab, macht Doctrine das genauso?

Wie siehts mit dem Pear Paket DataObjects aus? Ist das auch eine Alternative oder eher nicht?

**ModestLife** · 30.01.2008, 23:10

Bei Doctrine bin ich mir nicht sicher ob da auch die Model Klassen generiert werden oder nur der SQL Code?

Jap, Doctrine kann das. Und zwar zig Mal einfacher als Propel (ohne Phing und Konsorten).

http://www.phpdoctrine.org/documenta...ting-databases

**kaguya** · 31.01.2008, 09:26

Ah, das sieht wirklich gut aus, das macht die Entscheidung wieder schwieriger

Ist Doctrine denn auch wirklich stabil ? Version 0.10 macht mich da etwas stutzig...was man so liest soll es ja besser sein als Propel, aber auch besser als Propel 1.3 ?

[OOP] MVC und Performance