IceOnFire2323

Hallo zusammen !

Ich beschäftige mich seit einiger Zeit (theoretisch) mit verschiedenen MVC-Frameworks auf PHP-Basis. Von vorneherein möchte ich NICHT
generell die Sinnhaftigkeit von Frameworks in Frage stellen, die hab ich bereits erkannt. Vielmehr geht es um deren vernünftige Einsetzbarkeit in PHP-Applikationen.

Da ich nicht allwissend bin und grade die Konzepte und zugrundliegenden Paradigmen von Web-Applikationen studiere, bitte ich um eine konstruktive Diskussion.

Nun zu dem Thema, dass in mehrere offene Fragestellungen resultiert:

PHP-Frameworks gibt es mittlerweile massenhaft, teils mit unterschiedlicher Komplexität. Grundsätzlich sollen diese typische Aufgaben wie das Request-Handling mit entsprechenden Patterns standardisieren, so dass Entwickler sich mit der konkreten Aufgabe und dessen Problemlösung beschäftigen können. Ich habe gesehen, dass es viele elegante Lösungsansätze
bei den (PHP)-Frameworks gibt, die zugleich aber eine Komplexität mit sich bringen, die einen nicht unerheblichen Overhead bei der Behandlung eines jeden Requests erzeugen.

Exemplarisch:
ActionMapping laden, Konfigurationsdaten laden (teils XML), komplexe Objekt-Instanzen wenn nicht sogar ganze Hierarchien erzeugen, Framework-Code laden etc.


Da diese Aufgaben aufgrund des Http-Ping-Pong-Verhaltens bei jedem Request erneut ausgeführt werden, stellt sich mir die Frage ob dieser Overhead in Bezug auf die eigentlich zu lösende Aufgabe gerechtfertigt ist bzw. aus Performance-Sicht für eine stark frequentierte Web-Applikation überhaupt sinnvoll zu bewältigen ist.

Ich ziele insbesondere auf den Aspekt ab, dass es bei PHP keine request-übergreifende Persistenz gibt (z.B. allgemeingültige globale Arrays mit Konfigurationsparametern) und bei jedem Request der gesamte LifeCycle des Frameworks erneut instanziert werden muss. Es wundert mich daher, warum es ein Bestreben gibt, in Form von PHP-Frameworks diese Prozesse extrem zu abstrahieren, wenn zugleich dieser generische Code quasi nicht-abstrakt genutzt werden kann.

Oder anders ausgedrückt, wozu gibts ein PHP-Framework das z.B. mit dem FrontControllerPattern von einem konkreten Request abstrahiert und alle Requests gleich behandelt, wenn gleichzeitig immer eine request-gebundene Instanz dieses Controllers für einen konkreten Request erzeugt und nach
dessen Abarbeitung direkt wieder zerstört wird.


Ich hab vor nicht allzu langer Zeit an einem grösserem Projekt mit Java-Servlets gearbeitet. Natürlich kann man Äpfel nicht mit Birnen vergleichen, aber der wesentliche Unterschied zwischen Servlets und PHP-Apps besteht doch darin, dass es bei Servlets eine request-übergreifende Persistenz und einen echten konzeptionellen LifeCycle gibt.

Ich habe bereits PHP-Frameworks gesehen, die sich nahezu vollständig an diesem Lifecycle orientieren (z.B. Lion Framework), dessen Vorteile in Wirklichkeit aber nicht umsetzen können. Was bringt es eine hübsche Framework-Fassade aufzubauen, wenn die Innenwände diese erst gar nicht tragen können ?!

Z.B. müssen doch XML-basierte Konfigurationsdaten bei jedem Request erneut eingelesen können, der Request wird durch ein komplexes Framework-Klassensystem durchgereicht, erfüllt irgendwann mal seine (vielleicht minimalistische) Aufgabe und dann wird alles wieder geschlossen und sauber terminiert.

Im Netz finden sich in englischsprachigen Foren teils sehr kontroverse Diskussionen zu dieser Thematik. Dort wird meistens argumentiert, dass PHP != Java ist, PHP für das Servlet-Paradigma nicht konzipiert wurde, niemand eine "Javasierung" von PHP wünscht und die Vorteile von PHP im KISS-Prinzip liegen ... usw. Auf der anderen Seite bringen grade diese Kritiker den Wunsch nach vorne, PHP immer mehr im "Enterprise-Bereich" einsetzen zu wollen.

Manchmal wirds dort sehr unsachlich, da viele das Servlet-Konzept direkt mit der Sprache Java in Verbindung bringen - für mich ist das Servlet-Konzept theoretisch aber sprachungebunden: Wie man bereits an solchen komplexen Frameworks sieht. Ich hab hier schon einige Themen gelesen und mir gefällt die offene und vor allem sachliche Art und Weise, wie hier diskuttiert wird. Daher hoffe ich hier eher bereichert zu werden.

Vor allem frage ich mich: vermisst den niemand in der PHP-Welt, der mit Frameworks und darauf aufbauenden komplexen Web-Applikationen arbeitet eine Möglichkeit, über mehrere verschiedene Client-Requests hinweg und innerhalb eines abgegrenzten Kontexts persistent Daten und abstrakte Basis-Klassen speichern zu können ?!


Meiner bescheidenen Meinung nach würden doch dann erst solche komplexen Frameworks Sinn machen, wenn diese die allgemeingültigen applikations-gebundenen Daten ohne ein ständiges Neuladen aus einem persistenten Speicherbereich laden könnten. Dito bestimmte abstrakte Basisklassen wie
z.B. so ein Front-Controller oder eine FilterChain die was auch immer erledigt.

So, Text ist ein bisschen langatmig geworden, hoffe es macht nich allzu viel Arbeit. Grüße !

Mister Ad

nikosch

Ganz einfach: Weil fortgeschrittene Programmierung einen Bedarf nach Fragmentierung der Anwnedung haben, nach Abstrahierung bestimmter Prozesse und nach einheitlichen Schnittstellen auf Strukturen und Daten.

Requestparameter sind ein Beispiel für ein solche Schnittstellenproblematik. In einer Anwendung ohne Framework, kann jeder Bestandteil wahllos Parameter ändern, löschen, nachträglich setzen.
Oder:
Die Auswertung einer auszuführenden Action ist ohne Controllerpattern bereits bei kleinen Formularen (bspw. mehrstufigen) schnell kleinteilig, unübersichtlich und codetechnisch aufgebläht. Eine Generalisierung des Prozesses schafft ein einheitliches Vorgehen, selbst wenn dieses nicht für alle Zwecke immer optimal sein mag.


Die Alternative sind zig Include, die eigene Parameter an unzähligen Stellen definieren, sich gegenseitig Variablen- und Namensräume überschreiben und im schlimmsten Falle das Einbinden einer weiteren Komponente so verhindern.

Natürlich, aber das ist nun mal Wesen der Sprache, genauer des Mediums.


Im Endeffekt sind die meisten Antworten erst richtig verständlich, wenn man in der täglichen Arbeit mit und ohne Framework mit den Einzelthemen konfrontiert wurde.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

robo47

Gerade das parsen und umwandeln einer yaml/XML/ini/sonstwas-Datein in ein "Config-Objekt" oder Array lässt sich doch problemlos cachen, Objekt sowie arry lässt sich einfach serialisieren und dann z.b. in APC / memcache / xcache ablegen.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

nikosch

Für „Hello world!“ wird sicher niemand ein Framework nutzen. Für solche Beispiele ist eine Entwicklung in ASP, .net, Servlets oder objektorientierten Sprachen doch generell Overhead.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

dr.e.

Ich denke, du solltest dich mit den verfügbaren Produkten nochmal näher beschäftigen. Das APF z.B. bietet dir in dieser Richtung einige Möglichkeiten:

• Page-Controller: dieser kümmert sich um die Verwaltung einer beliebig komplexen GUI-Struktur. So eine Komponente ist mir in der JAVA-Welt noch nicht einmal über den Weg gelaufen.
• Front-Controller: hier kannst du wie beispielsweise aus Struts bekannt Actions registrieren und ausführen. Das sogar in Integration mit dem Page-Controller, so dass du auch nach dem Erstellen des DOM-Baums und nach der Transformation Actions ausführen kannst.
• Taglibs: das APF unterstützt zusammen mit dem Page-Controller einen generischen Ansatz Taglibs - wie aus JAVA bekannt - zu implementieren. Hiermit kannst du hervorragend wiederverwendbare GUI Widgets schreiben. Highlight dabei ist die Abstraktion von Formularen, wobei jedes Element bereits Presetting, Validierung und Filterung beherrscht. Letzteres ist mir in der JAVA-Welt auch noch nicht über den Weg gelaufen.
• Filterung: das APF kennt Input- und Output-Filter, die für die jeweils dem Bereich zugewiesenen Aufgaben genutzt werden können. Sie sind mit Filtern des Servlet-Containers zu vergleichen.

Mehr Punkte möchte ich erstmal nicht nennen, es wird denke ich daraus klar, dass PHP-Frameworks ebenfalls eine sehr gute Basis für die Implementierung von Web-Applikationen haben. Da muss es meiner Erfahrung nach garkeinen Servlet-Container-Cache geben, Web-Applikationen lassen sich sogar sehr gut auch ohne implemenieren. Da ich nun seit einiger Zeit in der JAVA-Web-Welt unterwegs bin, kann ich nur eines sagen: für Web ist PHP deutlich flexibler. Alleine die Tatsache, dass ich zig Handstände unternehmen muss um an die wirklich relevanten Daten zu kommen, würde mich privat davon abschrecken, in JAVA größere Web-Projekte zu implementieren.

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

IceOnFire2323

Seh ich grundsätzlich ja genau so.

Versteh ich nicht ganz ?! Wenn ich eine Komponente schreibe, die sich in ein Framework einfügt dann hab ich in dieser trotzdem vollen Zugriff auf das globale POST- oder GET-Array. Oder was meinst du konkret ?

Mir gings ja nicht darum den Sinn eines Controllers in Frage zu stellen. Ich zielte hier, (in meinen Worten etwas umständlich ausgedrückt) darauf ab, warum eine komplexe Controller-Hierarchie benötigt wird. Diese Hierarchie so abstrakt zu implementieren, dass sie mit jedem Request umgehen kann, anschliessend zu instanzieren, zu initialisieren und nach dem der einzelne Request durch is ... Puff weg damit. Und dann für den nächsten Request wieder der komplette (komplexe) Erzeugungsprozess. Schreit das nicht nach dem Bedarf einer speicherresidenten Instanz des bzw. der ganzen Controller, wenn die Implementierung eh schon von konkreten Requests so stark abstrahiert ?! Generalisierung: einverstanden!

Keine gute Alternative, daher mein Wunsch nach einem Applikationskontext, in dem diese Sachen erhalten bleiben. Technische Realisierung erstmal aussen vor.

Das ist doch nicht umbedingt eine Frage der Sprache an sich. Die Persistenz unterliegt dem zugrunde gelegten LifeCycle-Konzept, das theoretisch in Bezug auf eine Sprache generisch ist. Ist hier nicht die Art und Weise, wie der Apache die Requests behandelt das Wesen ... ?!

IceOnFire2323

Hatte ich auch nicht vor


Mir gings um das Verhältnis zwischen Framework-Overhead und der aktuellen Aufgabe des Requests unter dem Gesichtspunkt das in einer PHP-App immer alles neu erzeugt wird. Ökonomisch ist dat nich.

Ich betrachte das ungefähr so:
Wir bauen ein Haus, an dem 20 Bauarbeiter alias Requests arbeiten. Jeder Bauarbeiter hat seine eigene Palette an Werkzeugen, Bagger, Kran, Schubkarre, wat auch immer (Basis-Elemente des Frameworks einschliesslich der gesamten Config etc.). Jeder Bauarbeiter erfüllt unterschiedliche Aufgaben, für welche die (oder alle) Werkzeuge benötigt werden.

Was passiert nach Feierabend ?! (alias Request beendet) Die lassen ihr Zeugs auf der Baustelle !

Wie machen es PHP-Frameworks ?! Die nehmen abends dat ganze Zeugs, also den Bagger, Kran etc. mit und schleppen ihn am nächsten Morgen (alias neuer Request) wieder aufn Bau. Macht das Sinn ?!


Ich kämpfe mich grade durch den Code des Lion-Frameworks und es ist erstaunlich, was dort alles geladen und instanziert werden muss um einen Request zu bearbeiten. Betrachte das mal unter dem Aspekt, was wäre, wenn alles schon im Speicher liegt und nur noch benutzt werden muss / kann.

Und so heavy, wie die aktuellen PHP-Frameworks bereits hinter den Kullissen sind, wird jeden morgen erstmal der Bagger zum Bau geschleppt anstatt direkt in den Bagger einzusteigen und loszulegen.

PS: Der Vergleich mit Werkzeugen und Framework-Komponenten hinkt ein wenig, da sowas wie ein FrontController von allen Bauarbeitern alias Requests benutzt wird. Mir gehts einzig um den Aufwand (Performance der App) alles wieder anzuschleppen.

IceOnFire2323

OK Teilproblem mit Config-Daten gelöst, hab ich auch schon dran gedacht.
Wird nur lästig wenn du ein halbes Framework serialisiert in den Cache legen willst.

Ich stelle hier das gesamte Grundkonzept von (komplexen) php-basierten Frameworks vor dem Hintergrund der nicht vorhandenen Applikationspersistenz und in Bezug auf Effizienz in Frage und suche einen Meinungsaustausch ob sowas sinn- und wünschenswert wäre.

nikosch

Was ich meine ist: Wenn meine Controller bspw. Requestparameterhandling bereitstellen, Sessions als Objekte (Persistenzschicht?) abstrahieren und dergl. ist es schlicht unklug, weiter direkt die Superglobalen zu benutzen.
Ich habe auch mit vielen höheren Programmiersprachen Möglichkeiten, meine Prozesse auf Systemebene umzusetzen. Trotzdem benutze ich ja auch hier eher die Sprachfeatures. Frameworken ist doch immer eine Frage der Konvention, oder? Klar kann ich ausbrechen, dann stellt sich aber die Sinnfrage.
Das meinte ich mit Medium. Maßgeblich ist ja die zustandslose Arbeitsweise des HTTP-Protokolls. Eine Persistenz ist nur sehr schwierig umsetzbar, vgl. die Diskussion rund um Sessions.
Gottlob kommen jetzt bspw. Namespaces als Sprachfeature.

[edit] Noch was: Persistenz bedeutet natürlich auch was anderes: Immer einen ganzen Brocken im Speicher bereitzuhalten. Wenn man jetzt mal einen intelligenten Controller betrachtet, der bspw. je nach Action oder Ziel-Content-Type erstmal Module nachlädt, verteilt sich der Overhead schon wieder etwas anders, oder?

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

IceOnFire2323

Mir gehts nicht um die konkreten Potentiale eines Frameworks, auch nicht um einen direkten Vergleich mit der Java-Welt und ob Java besser is oder nicht. PHP ist was OOP-Konzepte betrifft sehr mächtig geworden. So einen Vergleich anzuzetteln endet immer im FachBlaBla-Krieg. Beide Sprachen haben ihre guten Stärken und ich arbeite mit beiden sehr gerne.


Meiner Auffassung nach wird nur unter PHP mit komplexen Frameworks etwas versucht, was aus konzeptioneller Hinsicht ineffizient ist oder andersrum effizienter gemacht werden könnte. Das hat nicht mal konkret etwas mit PHP zu tun, sondern mit der Art und Weise, wie unter PHP der Apache die Requests behandelt und was der Apache für PHP zur Verfügung stellt und insbesondere was eben nicht!

Nachträglich hinzugefügt:
Sowohl PHP, als auch dessen Einsatzgebiete haben sich in den letzten Jahren massiv verändert. Die Anforderungen und die Professionalität von PHP-basierten Anwendungen haben stark zugenommen.
Die Zeit der Kinderschuhe ist vorbei, das sieht man u.a. deutlich an den komplexen Frameworks die aus
dem Boden spriessen. Gleichzeitig wächst aber die konzeptionelle Art und Weise wie PHP-Code behandelt wird nicht mit. Apache behandelt PHP immer noch so, als ob es ein stupides sequentiell abzuarbeitendes Skript wäre. Deswegen stelle ich die Effizienz von PHP-Frameworks in Frage, weil diese Schuhgröße 45 für einen Unterbau mit Schuhgröße 35 sind. Ein Basis-LifeCycle mit applikationsorientierten Kontext, der zudem persistent ist, kann helfen die fehlenden 10 Größen auszugleichen. Einverstanden ?!
Ende von "Nachträglich hinzugefügt":


Flexibilität ist eine deutliche Stärke von PHP, da ich selbst an einem nicht grade kleinen Java-Projekt gearbeitet habe (180 Klassen, MVC-Architektur im Eigenbau mit FrontController, Command-Pattern, Service-Layer u.s.w.), weiss ich wie haarsträubend Java sein kann. Halt überkorrekt diese Sprache.

Aber wie gesagt, mir gehts nicht um Java, sondern um das Konzept wie dort
ein echter und klar definierter LifeCycle gegeben ist. Den kann man mit jedem Framework und in (fast) jeder Sprache der Welt imitieren und natürlich um auf die von dir genannten Vorteile des APF zu sprechen zu kommen auch deutlich besser gestalten. Aber dort wird eben alles für jeden x-beliebigen Request vom Tomcat im Speicher gehalten und nicht für jeden neuen Request inkludiert und neu instanziert.


Prima: du kennst dann doch den Vorteil von ContextListenern, dem ServletContext und ServletConfig. Wenn man das rein konzeptionelle von dort nimmt und mit der Flexibilität von PHP paart, dann hat man die Grundlage für ein effizientes Framework (was es kann spielt erstmal keine Rolle), dass ohne dem permanten Neuladen des Framework-Codes auskommt. Oder nicht ?!