Erfahrungen mit Frameworks wie Zend, ezComponents, SilverStripe ?

[*Maiki]

Hallo,

wer hat Erfahrungen mit Frameworks wie dem von Zend, ezComponents oder auch SilverStripe, ggf. Erfahrungen mit weiteren PHP-Frameworks?

Was lässt sich zu Stärken und Schwächen sagen?

Gruß Maik

[Kropff]

Also ich habe mich mit dem Zend Framework (ZF) und CakePHP beschäftigt. Der Vorteil vom ZF ist, dass es im Gegensatz zu Cake nicht installiert werden muss. Das ist schon mal ein Vorteil. Allerdings ist imho die Performance ein wenig dürftig. Und es wirkt auch ein wenig zu überladen. Hängt allerdings vom Anwender ab.

Peter

[PHP-Desaster]

Ich verwende das Zend Framework und das ist einfach super. Nicht nur sind die einzelnen Komponenten sehr professionell entwickelt, diese lassen sich auch sehr leicht einzeln verwenden. Das bekommen die meisten anderen Frameworks einfach nicht gebacken. Die Performance ist ok, wenn man auf diesem hohen OOP-Niveau entwickelt. Man darf natürlich nicht mit einfachem prozeduralen Code vergleichen und eben auf Kriterien wie Wiederverwendbarkeit und Wartbarkeit achten.
Die ezComponents habe ich mir mal ein wenig angesehen und die wirken ganz gut. Zu der Verwendbarkeit kann ich nicht viel sagen.
Von SilverStripe habe ich mir nur irgendwann mal die CMS-Demo angesehen, sonst kann ich da nichts zu sagen.
Wenn die Entscheidung im Grunde egal ist, da Neuentwicklung, etc. würde ich auf jeden Fall auf das ZF setzen. Die Kernentwickler von PHP stehen da hinter und wird in Zukunft bestimmt noch immer bekannter und wichtiger werden. Für bestimmte Komponenten kann man ja immer noch die ezc-Implementation verwenden.

[martin2]

ZF ist sehr gut und man kann sich die Komponenten die man benötigt rausziehen, ähnlich wie bei der pear, nur was ich brauche muss ich instaliieren. Cake und Sympfony gefallen mir persönlich nicht so gut, aber das ist Geschmackssache, ezComponets sehr schön.
Wie bei allen Framewokrs egal welcher Sprache gilt: es wird immer unnötiger Overhead produdziert, liegt in der Natur der Sache.

Der Vorteil von Frameworks ist halt das sie dir lästige Aufgaben abnehmen, und wenn man sich da einmal durchgefuxt hat dann sind die sehr toll.

Da inzwischen fast alle Frameworks das MVC Pattern inmplementieren sind sie alle recht einfach zu erlernen. Also anschauen und angucken und überlegen was ich ich überhaupt brauche und welches Framework kommt meinem persönlichen Gefühlen am nächsten.

[tim-gt]

Ich stelle mir zur Zeit die Frage, ein eigenes MVC-Framework zu entwickeln, da ich die gesamte Funktionalität von Zend etc. niemals brauchen werde und der Lerneffekt wohl auch etwas höher ist. Ausserdem definiere ich die Klasse, die sich z.B. ums Errorhandling/Exceptionhandling dreht, lieber ganz alleine. Drawback: Ist extrem zeitintensiv.. Im Moment entwickle ich noch eine Website für meinen Arbeitgeber im Rahmen eines Praktikums, und hier drängt die Zeit, also kann ich nicht alles umsetzen, was ich will. Nachher werde ich aber versuchen, die Grundideen von MVC umzusetzen, es gibt schliesslich einige gute Tutorials/Denkanstösse im Netz, was vielleicht den Threadstarter auch interessieren wird:

MVC mit PHP - Das MVC-PAttern mit PHP implementieren und verwenden
[Tutorial] Mein eigenes MVC-Framework: Artikelübersicht
Understanding MVC in PHP - O'Reilly Media

Ich mach das vor allem, weil mich OOP an sich interessiert und ich im Rahmen meines Studiums nächstes Semester mit Java konfrontiert werde, was ja wohl viele Gemeinsamkeiten hat. Es ist jetzt aber nicht so, dass ich massenhaft professionelle Websites ins Netz stelle und mir dabei ne goldene Nase verdiene, deshalb frage ich mich manchmal schon, ob sich der Aufwand überhaupt lohnt ;-)

[unset]

Ich stelle mir zur Zeit die Frage, ein eigenes MVC-Framework zu entwickeln, da ich die gesamte Funktionalität von Zend etc. niemals brauchen werde und der Lerneffekt wohl auch etwas höher ist. Ausserdem definiere ich die Klasse, die sich z.B. ums Errorhandling/Exceptionhandling dreht, lieber ganz alleine. Drawback: Ist extrem zeitintensiv..

Du musst ja nicht das ganze Framework einsetzen. Ich zum Beispiel habe mir mein beruflich eingesetztes ebenfalls vom Zend-Framework abgeleitet. Prinzipiell kaum wiederzuerkennen, aber Standardgeschichten sind eben schon da –*und müssen nicht nochmal gebaut werden.

Das würde ich einer kompletten Neuentwicklung jedenfalls vorziehen.

[unset]

Und in Zukunft bitte editieren, statt zwei Posts hintereinander zu knüppeln. Ist ja nicht so, als würde das Thema seit Wochen in der Versenkung liegen. ;-)

[h3ll]

PowerSite - ein extrem flexibles PHP Framework

Ist ein ziemlicher Mischmasch aus PHP 4 und PHP 5 Code, prozeduraler Programmierung und objektorientierter Programmierung und viel global Gepfusche.

Der Code sieht auch optisch ziemlich schlampig aus (unsauber eingerückt; Stringverkettung einmal mit, einmal ohne Abstand; usw.).

Saubere Programmierung sieht anders aus.

Mit sowas würd ich nicht arbeiten wollen.

[unset]

Die Diskussion ob das Ding gut oder schlecht ist und die virtuellen Schwanzvergleiche und das rumgeprahle mit irgendwelchen Pseudo-Szene-Wörtern können gerne in einem extra dafür eingerichteten Thread stattfinden. Wollt ihr das hier unbedingt weiterführen, kann ich die entsprechenden Posts gerne heraustrennen.

[h3ll]

Entscheidend ist was die echten Profis davon halten und wenn die dafür zahlen und es reichlich problemfrei nutzen ist das absolut ok.

Nur blöd, dass ich wirklich ein echter Profi bin und nix davon halte.

Glaub mir, die hätte ich sofort am Halse, wenn das nicht laufen würde, denn die prüfen ernsthaft bevor sie etwas überhaupt bezahlen oder gar dran denken einen solchen Titel überhaupt einsetzen zu wollen.

Wenn ich bei uns in der Firma so einen Code abliefern würde, würde ich nicht mehr lange in der Firma arbeiten.

[combie]

Wenn ich bei uns in der Firma so einen Code abliefern würde, würde ich nicht mehr lange in der Firma arbeiten.

Aber auch im ZF ist nicht alles Gold, was glänzt.
Das ein oder andere Singleton dümpelt da rum, und ich habe KA warum.
Die ganzen eingestreuten require* nerven, weils ohne includepath nicht geht.
Das halbgare Autoloading... entweder überall require* einstreuen, oder Autoload. Aber doch nicht solch ein durcheinander.

Ich sezte auch häufiger mal ein paar Teile des FW ein. Z.b. Zend_Soap_Server mit seiner automatischen WSDL generierung halte ich für recht gelungen. Auch das Mail Gedöns ist gut brauchbar. usw.

[martin2]

Aber auch im ZF ist nicht alles Gold, was glänzt.
Das ein oder andere Singleton dümpelt da rum, und ich habe KA warum.
Die ganzen eingestreuten require* nerven, weils ohne includepath nicht geht.

stimmt, abe im ZF werden solche Fehler nach und nach ausgemerzt das autoloading ist noch nicht so das wahre aber auch das wird von release zu release besser. das einbetten der Singelton war wohl etwas über ziel hinausgeschossen.

[h3ll]

Aber auch im ZF ist nicht alles Gold, was glänzt.

Da stimm ich dir voll zu. Aber in professionellen Kreisen wird es trotzdem sehr gerne verwendet. Einerseits, weil es sehr gut dokumentiert ist, andererseits weil die Zend-Leute dahinter stehen und es stetig weiterentwickelt wird.

Jedes Framework hat irgendwelche Macken. Aber trotzdem gibts auch gute und eher schlechte Frameworks. Mit der Zeit entwickelt man ein Auge dafür, welche gut und welche schlecht programmiert sind, und welche für die geplante Aufgabe am geeignetsten ist.

Ein Framework, das großteils aus prozeduralen Code besteht und das so formatiert ist, als hätte es ein Anfänger getippt ist nicht gerade vertrauenerweckend und lässt an den Künsten der Ersteller zweifeln. Und ehrlich gesagt würde ich mich als Entwickler mit sowas nicht beschäftigen wollen. Da programmier ich lieber von Grund auf ein neues Framework, anstatt ein fertiges zu verwenden, das unsauber zusammengeschustert ist. Vor allem mit den Variablen und Funktionen im globalen Namensraum stößt man früher oder später auf Probleme. Das ist alles andere als professionell.

[combie]

Ich habe mir das Ding von piratos auch mal angesehen.....
(sonst hätte ich nicht so grinsen können)

Die schlimmsten Auffälligkieten:
1. ein Urwald von Konstanten
2. __autoload macht SPL Autoload kaputt
3. zudonnern des globalen Namensraumes (Funktionen, Konstanten u. Variablen)


Meine index.php sehen meist so aus, oder so ähnlich:

<?php

require_once "./Config/Application.php";

$Application = new Application;
$Application->run();

Wobei dann $Application die einzige globale Variable ist. Und das auch nur weil es nicht anders geht. Sie wird auch nur in dieser Datei verwendet.

[PHP-Desaster]

Wobei dann $Application die einzige globale Variable ist. Und das auch nur weil es nicht anders geht. Sie wird auch nur in dieser Datei verwendet.

Naja, so teilweise. Ich packe noch eine Bootstrap-Klasse drumherum, welche die eigentliche Anwendungsinstanz erzeugt. So sind mehrere Anwendungen über das gleiche Skript abrufbar und die Anwendungsinstanz ist nichtmal global.
Sieht dann so aus:

<?php
define('BOOTSTART', microtime(true));

require_once 'bootstrap.php';
Bootstrap::dispatch();

Nur um selbst noch die letzte Globale zu killen