-
pushWP erweitert euren Wordpres-Blog um ein paar Features, die helfen sollen ihn noch bekannter zu machen.
Mit BlockRules sind Wordpress User in der Lage bestimmte Inhaltsblöcke unter bestimmten Umständen anzuzeigen.
pushWP erweitert euren Wordpres-Blog um ein paar Features, die helfen sollen ihn noch bekannter zu machen.
Mit BlockRules sind Wordpress User in der Lage bestimmte Inhaltsblöcke unter bestimmten Umständen anzuzeigen.
A.d.R. Wem dieser Artikel gefällt, sollte den hervorragenden Blog von Ralf Eggert besuchen.
Die Diskussion über den Einsatz von PHP Frameworks ist so alt wie die Welt. Jeder PHP Entwickler, der bei drei nicht auf dem Baum ist, hat sicher schon mal sein eigenes Framework geschrieben bzw. seine eigene lose Klassensammlung, die er selber dann als Framework bezeichnet. Viele haben sogar mehr als eines verbrochen geschrieben.
Ich selber habe in den letzten 10 Jahren, in denen ich intensiv in PHP entwickelt habe, auch mehrere „Frameworks“ für unterschiedliche Projekte geschrieben. Oftmals kamen die dann nur in einem oder maximal zwei Projekten zum Einsatz, weil am Ende des Projektes die Erkenntnis in mir wuchs, dass das Framework doch nicht so toll und flexibel ist, wie ich vorher dachte.
Heute bin ich nicht mehr bereit, meine kostbare Entwicklungszeit in ein eigenes Framework zu investieren, das außer in meinem Unternehmen sonst nirgends mehr eingesetzt wird. Wie der eine oder die andere weiß, beschäftige ich mich derzeit beruflich sehr mit dem Zend Framework. Somit könnt ihr leicht erraten, dass dieses Framework derzeit meine erste Wahl ist.
Immer wieder verfolge ich teilweise sehr energisch geführten Diskussionen über den Einsatz eines Open Source PHP Frameworks und immer wieder höre ich die selben Gründe, die gegen den Einsatz eines PHP Frameworks sprechen. Diese Gründe möchte ich in diesem Beitrag einmal sammeln und danach diskutieren.
1. Bevor ich mich in fremden Programmcode einarbeite, schreibe ich das schneller selbst.
Der Klassiker schlechthin! Ich möchte den PHP Entwickler sehen, der eine komplexe MVC-Komponente schneller schreibt, als er sich in eine vorhandene einarbeitet. Ok, dies setzt natürlich voraus, dass diese Komponente des Frameworks auch gut dokumentiert ist und es auch ausreichend Beispiele für den Einsatz gibt. Es setzt aber auch voraus, dass man in der Lage ist, sich in fremden Programmcode einzuarbeiten. Wer dauerhaft als PHP Entwickler seine Brötchen verdienen möchte, sollte dazu in der Lage sein. Und hat man sich erst einmal eingearbeitet, dann gewinnt man am Ende viel Zeit für die eigentlichen Kundenprojekte.
2. PHP Frameworks sind voller Bugs, man schaue nur auf die langen Listen mit Bugfixes bei jedem Release.
Zuerst einmal: es gibt keine Software ohne Bugs! Es gibt nur Software, in der noch nicht alle Bugs gefunden wurden. Eine lange Liste an Bugfixes spricht nicht unbedingt gegen ein Framework, sondern sogar dafür. Denn je mehr Entwickler dieses Framework einsetzen, desto schneller werden Bugs gefunden. Zudem sind viele Bugs auch eher Erweiterungswünsche. Und auch dein eigenes Framework wird unzählige Bugs beinhalten. Diese hat nur noch niemand gefunden, weil es außer dir niemand nutzt… 
3. Da der Programmcode des PHP Frameworks öffentlich zugänglich ist, mache ich meine Anwendung unsicher. Schließlich können die Hacker den Programmcode des Frameworks auch einsehen.
Unsichere PHP Anwendungen entstehen sicherlich nicht aus dem Einsatz eines PHP Frameworks. Die meisten PHP Frameworks unterstützen den Entwickler sogar dabei, die eigene Anwendung sicherer zu programmieren. Viele Sicherheitsprobleme resultieren aus nicht ausreichend gefilterten und validierten Eingaben der Anwender. Und diese Fehler machen unkundige Entwickler egal, ob sie ein frei verfügbares Framework einsetzen oder nicht.
4. Das Framework XYZ ist völlig überladen, ich brauche nur 2 oder 3 der 40 Komponenten.
Wenn das Framework über eine solide Architektur verfügt, dann sollte es kein Problem sein, dass du dich nur auf die Komponenten konzentrierst, die du wirklich brauchst. Bei einem Full-Stack-Framework kann dies jedoch etwas schwieriger werden. Ein Beispiel: Entfernt man z.B. beim Zend Framework alle require_once() Aufrufe und setzt stattdessen Autoloading ein, werden auch keine Komponenten im vorauseilenden Gehorsam geladen, auch wenn man sie nicht braucht. Und wer nur Zend_Controller und Zend_View aber nicht Zend_Pdf, Zend_Search_Lucene und Zend_HasteNichtGesehen einsetzen möchte, soll das auch gerne tun. Die meisten Komponenten sind lose gekoppelt.
5. Das Framework XYZ ist nicht vollständig, mir fehlen 2 bis 3 Komponenten!
Wer wegen 2 oder 3 fehlenden Komponenten lieber ein komplett neues Framework schreibt, hat eindeutig zu viel Zeit. Da macht es doch mehr Sinn, für ein vorhandenes Framework passende Erweiterungen zu schreiben und diese dann auch der Allgemeinheit zur Verfügung zu stellen. Hat auch den geschmeidigen Vorteil, dass auch andere die Komponenten nutzen und diese somit stetig verbessert wird.
6. Ich kenne gerne den gesamten Programmcode im Detail, so dass ich lieber alles selber schreibe!
Ok, du hast also ein Framework mit Komponenten für Datenbankabstraktion, Models, Controller, Templateverarbeitung, Filter und Validierungsmechanismen, Caching, Konfiguration, Volltextsuche, Authentifizierung, Autorisierung, Formularverarbeitung sowie 10 Webservices geschrieben. Das Framework ist sehr komplex, hat dich aber über 2 Jahre ständig in deiner Freizeit beschäftigt. Kennst du da wirklich den gesamten Programmcode noch im Detail? Ja, bei so einem Elefantenhirn solltest du aufhören zu programmieren und lieber in Quizshows auftreten… Aber im Ernst, jeder kennt das Phänomen, dass man nach längerer Zeit auch seinen eigenen Programmcode manchmal nur schwer bis gar nicht nachvollziehen kann.
7. Was mache ich, wenn das PHP Framework nicht mehr weiter entwickelt wird, weil die Hauptentwickler keine Zeit mehr haben?
Was machst du, wenn du keine Zeit mehr hast, dein eigenes Framework weiter zu entwickeln? Was machst du, wenn du Aufträge ablehnen musst, weil du für das eine Kundenprojekt noch dein Framework erweitern musst? Was machst du, wenn du wegen der Wartung deines Frameworks pro Jahr nur 2 bis 3 statt 23 bezahlte Projekte umsetzen kannst? Hmm, was machst du? Und vor allem, was kuckst du nun?
8. Für das Framework gibt es dauernd neue Releases, bin ja nur noch am aktualisieren.
Ich habe noch nie verstanden, warum neue Releases bei einem Framework ein Problem sein sollten. In einem neuen Release werden Fehler bereinigt und es werden neue Funktionalitäten hinzugefügt. Manche sind für dich wichtig, andere nicht. Und niemand ist gezwungen, jedes Release sofort einzusetzen. Du musst nicht unbedingt, den Wechsel von Version 1.8.3 auf 1.8.4 sofort mit machen, wenn klar ist, dass 1.8.5 schon in den nächsten Wochen kommen wird, und du nicht auf ein Bugfix oder eine Erweiterung in 1.8.4. angewiesen bist. Es sei denn, 1.8.4 schließt explizit eine neu entdeckte Sicherheitslücke. Dennoch solltest du regelmäßig neue Releases einspielen, um auf dem Stand der Entwicklung zu bleiben. Ein direkter Wechsel von einer 1.0 auf eine 2.0 Version ist deutlich aufwändiger, als ein Wechsel von 1.8 auf 2.0. Woher ich das weiß? Aus meiner Erfahrung.
9. Wenn mein Kunde mitbekommt, dass ich nicht alles selber programmiert habe, kürzt er mir das Budget!
Es tut mir natürlich Leid, dass dein Kunde so darauf ist. Ich bin mir aber ziemlich sicher, dass dieser Kunde auch dann Gründe finden würde, dein Budget zu kürzen, wenn du alles selber programmiert hast. Vielleicht sagt er ja: „Wie? Sie setzen kein PHP Framework ein und schreiben alles selbst? Zeit ist Geld! Und Sie sollten Ihre Zeit für mein Problem einsetzen und nicht das Rad neu erfinden! Ich kürze Ihnen das Budget!“
10. Ich schreibe mein eigenes PHP Framework, um zu lernen!
Ok, den Grund lasse ich ausnahmsweise mal gelten…
So, nun seid ihr dran. Wer kennt weitere gute oder schlechte Gründe gegen den Einsatz eines PHP Frameworks?
Meine Gründe sind nicht gegen Frameworks im Allgemeinen gerichtet, denn ich denke, dass Frameworks jeder Herkunft wichtig sind, da sie eine einheitliche Form zur Strukturierung vorgeben.
Dein viertes Argument zielt nur auf die Anzahl der Komponenten ab. Solange man nicht alle Komponenten verwenden muss, ist alles okay, aber wenn die Komponenten, die man verwenden möchte, überladen (”overengineered”) sind und das Laden der Seite für den angestrebten Funktionsumfang zu lange dauert, möchte ich ein solches Framework nicht verwenden. Wie soll man auch kommunizieren, dass Webseiten mit extrem kleinen Funktionsumfang bereits 0.5s zum Laden benötigen?
Ein weiterer Punkt, der nicht beachtet wurde, ist der eigene Geschmack, da hinter den verschiedenen Frameworks auch verschiedene Ideale stehen, die nicht jedem gefallen. Außerdem machen manche Frameworks selbst einfachste Aufgaben sehr kompliziert, um Abstraktion zu schaffen, die kaum einer benötigt. So was stört nicht nur beim Entwickeln, da man mehr Zeit benötigt, sondern demotiviert auch.
Für Freizeitentwickler – und das ist nicht unbedingt eine Nische – kann das regelmäßige Aktualisieren von neuen Versionen anstrengend werden. Aber auch das Einlesen in neue Features und Änderungen an Komponenten, die man bisher verwendet hat, kostet Zeit.
Insgesamt gebe ich dir jedoch Recht mit der Aussage, dass ein Framework verwendet werden sollte. Ob man ein eigenes entwickelt, das einen hinreichend kleinen Feature-Umfang hat, oder ob man eines der etablierten Frameworks verwendet, sei dahingestellt. Man sollte nur differenzieren zwischen Freizeit- und Berufsentwicklern, da die Anforderungen stark variieren können.
Wenn die Architektur eine gewisse Qualität hat, dann kann man Komponenten aus anderen Frameworks für das genutzte Framework einsetzen. Es spricht ja nichts dagegen, einen schlanken Kern nach eigenem Geschmack zu entwickeln und Komponenten eines anderen Frameworks – das Zend Framework ist hierfür sehr geeignet – zu verwenden.
11. Dein Framework wird nie so gut Dokumentiert sein.
Ok, hängt vom Framework ab, aber zb. Zend Framework find ich ausserordentlich gut Dokumentiert. Halt der Vorteil wenn eine große und aktive Community und eine zahlstarke Firma dahinter steckt. Dein eigenes Framework wirst du wohl maximal mit phpdoc dokumentiern, für was auch mehr zeit investieren. (siehe auch 6.)
und zu 3tens: Security by Obscurity hat doch noch nie funktioniert.
http://de.wikipedia.org/wiki/Security_through_obscurity
danke ralf.
Die meisten leute, die from scratch ein neues Framework schreiben wollen, übernehmen sich gnadenlos. Wie du im Artikel geschrieben hast, funktioniert das vielleicht mit ein zwei Projekten halbwegs gut bis bequem, aber irgendwann tun sich halt Schwachstellen auf. Und wie das nunmal in der freien Marktwirtschaft so ist: Wenn massiv umgestellt werden muss, fehlen die Ressourcen!
Ich persönlich begnüge mich damit, meine (manchmal etwas kruden) Anforderungen schlicht zu bestehenden Frameworks hinzuzuprogrammieren. Das Add-On nimmt dann zwar auch ähnliche Ausmaße wie ein eigenes Framework an, aber kritische oder grundlegende Dinge liegen eben doch in der Code-Basis, die von vielen Leuten gepflegt und erweitert wird. Das ist – IMHO – der goldene Mittelweg.
11. Ich bin der beste Programmierer der Welt. Andere Programmierer können das eh nicht so gut wie ich. Deswegen schreibe ich ALLES selber.
– Träum weiter…
[...] Frameworks hat so viele Vorteile, wie auch die Nutzung eines Erweiterbaren CMS. Eine Liste mit 10 Gründen gegen den Einsatz eines PHP Frameworks hat mich dann aufgeklärt… Juli 7, 2009 | In Web, Webdevelopment [...]
[...] 7. Juli 2009 | Autor: Ralf Eggert Heute morgen ist mein erster Artikel “10 Gründe gegen den Einsatz von PHP Frameworks” beim PHP Blog PHPhatesme erschienen. Ein kurzer Auszug: Die Diskussion über den Einsatz von [...]
Bei diesem Thema muss (ok sollte) man ganz klar zwischen Arbeit und Vergnügen trennen. Natürlich setze ich auf Arbeit Frameworks ein. Ich würde auch keinen der Gründe von einem Kollegen als Argument gegen den Einsatz von Frameworks gelten lassen.
Aber ich wäre doch kein Nerd wenn ich mir nicht 1) nach 10-minütigen Aufenthalt auf dem Balkon einen Sonnenbrand zuziehe und 2) meine Freizeit damit vergeude sinnlose Dinge zu programmieren.
zu Punkt 4 sein noch gesagt, das es da draußen noch Framework gibt die an der Prämisse festhalten auch unter PHP4 laufen zu können *schüttel*
11. Ich habe Support durch eine große Community.
Bei meinem eigenen Framework ist die Hilfe bei speziellen Problemen sehr eingeschränkt. Hier bekommt man meist nur Antworten auf allgemeine PHP-Fragen. Zu meinem Framework kann mir keiner helfen.
Bei bekannten Frameworks kann ich auf die Hilfe einer großen Community zurückgreifen. Sei es durch Foren, Mailinglisten etc.
12. Ich habe später bessere Chancen im Job
Viele Stellenausschreibungen erwarten mittlerweile Erfahrungen mit einem MVC-Framework. Sich damit auszukennen, kann nie verkehrt sein, wenn man seinen Lebensunterhalt damit verdienen möchte.
Ich bin mit CodeIgniter sehr zu frieden, es reicht für mich Privat vollkommen.
Bei der Arbeit benutze Ich auch das Zend-Framework
11. Ich verstehe Frameworks nicht und mache das dann lieber selber und mit der Sicherheit habe ich kein Problem – noch keine meiner Seiten wurde “berarbeitet” #ironie
Aber mal im Ernst: Klasse Artikel!
9. Wenn mein Kunde mitbekommt, dass ich nicht alles selber programmiert habe, kürzt er mir das Budget!
Richtig, braucht man für die Erstellung einer webseite zwei wochen anstatt vier, weil man als Basis ein Framework benutzt sollte man dem Kunden auch weniger verrechnen als wenn man ohne Framework mehr Zeit dafür braucht (gilt auch für die Wartung bzw das Erweitern der Webseite nachher).
Aber daraus resultieren eben zwei grosse Vorteile. Man braucht weniger Geld zu verlangen und ist so konkurenzfähiger gegenüber anderen Firmen. Falls zwei Firmen die gleiche Leistung anbieten, die eine aber zum halben Preis, wer glaubt ihr bekommt vum Kunden den Autrag?
Zweiter Vorteil, dadurch dass man anstatt 4 wochen gebraucht hat, da man ein eigenes Framework entwickelt hat, man es in zwei geschafft hat, so kann man doppelt soviele Aufträge an Land ziehn / bearbeiten!
3. Da der Programmcode des PHP Frameworks öffentlich zugänglich ist, mache ich meine Anwendung unsicher. Schließlich können die Hacker den Programmcode des Frameworks auch einsehen.
Dieser Punkt ist auch richtig. Dies war auch ein Grund warum wir am anfang etwas skeptisch Frameworks gegenüber waren. Besonders dramatisch ist dies bei Bugs die die Sicherheit betreffen.
Aber in eigenen Anwendungen Frameworks sind noch mehr solche Probleme versteckt und meistens werden die von Hackern entdeckt bevor man sie selbst bemerkt.
Bei Frameworks die vun vielen benutzt werden, werden diese Bugs oft entdeckt bevor sie ein Hacker ausnutzen kann. Wenn also regelmässig bugfixes aufspeilt werden ists kein Problem.
Das Problem ist, man kann nicht immer ein Framework einfach ersetzen, da neben den Bugfixes auch andere “Sachen” geändert wurden und somit die eigene Anwendung inkompatibel mit dem neusten Release ist. Dann muss man entweder nur die unsichere Komponente ersetzen oder die eigene Anwendung anpassen.
Beim Zend Framework finde ich sehr gut dass das Team / die Community es soweit möglich verhindert änderungen vorzunehmen die zwar Sinn ergeben aber auch komatibilitäts Probleme einführen für Anwendungen die auf älteren Versionen des Frameworks laufen / liefen.
Selbst wenn ich kleine Webseiten mit wenig Funktionsumfang programmiere, sollte ich ein Framework einsetzen, weil es eben die Basis-Funktionalitäten (und Sicherheiten!) schon abbildet. Man sollte höchstens auf ein Framework verzichten wenn man dafür ein CMS einsetzt was für die meisten Entwicklungen auch Sinn macht. Bei kleinen Seiten mit 100 Besuchern die Woche ist es doch auch total egal ob die Seite 0.2s oder 0.5s zum Laden benötigt, seien wir doch mal ehrlich.
Wordpress wird ja auch zu 95% als Blog-Software eingesetzt obwohl die Code-Basis eine mittlere Katastrophe ist.
Super Artikel, gerne gelesen. Zum 10. Punkt würde ich noch den Spaß hinzufügen.
Gerade am Anfang und beim lernen hat es mir einfach Spaß gemacht diverse Dinge selbst zu entwickeln und zu benutzen.
Der wird dann abgelöst und vergrößert wenn man mit einem “richtigen” Framework arbeitet 
[...] Warum man als PHP-Entwickler vielleicht doch lieber auf ein fertiges Framework setzen sollte, anstatt selbst „schnell mal eins zu schreiben“, darüber schreibt Ralf Eggert auf „PHP hates me“. [...]
Ich schreibe auch gerade mein eigenes Framework. Seit 3 Jahren. Glücklicherweise mache ich das nicht allein. Un habe keine Kunden sondern eine Open Source Community, die das auch noch gut findet
http://flow3.typo3.org
@Robert Ich glaube ein Framework schreiben, um ein gutes Framework zu haben ist eine andere Sache (besonders, wenn man vor 3 Jahren angefangen hat). Ein Framework zu schreiben, um eine Webseite zu bauen halte ich für … naja suboptimal.
Würdest du denn heute nochmal flow3 starten? Hab’s leider nie verwendet, kenne also die Benefits nicht wirklicht.
Zend-FW ist programmieren des programieren willens. Für ein einfaches formular muss man mehr zeilen code schreiben als das formular felder hat, ohne auch nur das Datenbank backend angefangen zu haben.
Und wenn dann mal nichts funktioniert dann kommt eine sinnlos nichtssagende Exception von irgendeiner subclasse anstatt dass der volle sql quellcode ausgegeben wird.
Das ist doch kein vortschritt, das erleichtert doch nicht dass erstellen von produkten.
Ein System muss Dir sinnvolle Fehlermeldungen geben, und auch weiterlaufen wenn Teile gerade nicht funktionieren.
Es ist daher sehr wohl notwendig dass die Menschheit noch an vielen Frameworks bastelt. Damit dann als Ergebniss ein Lego für Programmieren herauskommt.
Wir sind programmiertechnisch im tiefsten mittelalter.
@christian: ich nutze das ZF. Generische Modell-Controller können entsprechende Formulare erzeugen. Das habe ich einmal geschrieben und seitdem nie wieder. Stimmt, hat mehr Zeilen, als das Formular hat, aber ich musste es nur einmal tun …
Mal ganz abgesehen davon, dass die Behauptung schlicht und ergreifend falsch ist
Die Einarbeitung in ein Framework ist nicht unbedingt leicht. Das hält sicher viele davon ab. Aber man gewinnt langfristig ein hohes Maß an Flexibilität und gerade das Zend Framework gibt eine gute Dateistruktur vor, die sich auch in der Übersichtlichkeit von eigenen Erweiterungen bezahlt macht.
Wenn vorhandene Projekte umgebaut werden sollen, kann es allerdings auch schwierig und langwierig werden. Das würde ich nur machen, wenn das alte Projekt so verkorkst ist, dass ich mir jedesmal die Haare raufe, oder wenn ich mehrere Projekte zusammenfassen will. Bei einer einigermaßen guten Basis beginne ich inzwischen, Komponenten des Zend Frameworks zu nutzen und die MVC-Struktur langsam in eine Richtung zu entwickeln, mit der ich auf lange Sicht auch die Komponenten von ZF verwenden kann.
Sicherlich ist das nicht unbedingt 100% das richtige Ausgangsthema, aber ich denke es ist dennoch nah genug dran.
Mich würde interessieren, wie ihr den Einsatz von Propel und Doctrine bewertet. Ich habe bisher noch nicht den Mut gefunden, eines der beiden Verfahren einzusetzen, obwohl ich zu einem gewissen Teil die zugrundeliegende Idee sehr gut finde.
Ich hatte bisher mit einigen Anwendungen zu tun, in denen recht große in Beziehung stehende Datenmengen verwaltet wurden. In den Anwendungen war OOP noch kein großes Thema. Ich frage mich jedoch, wie würde ich heute vorgehen, wenn ich wieder mit solchen Datenmengen hantieren müsste?
Ist die Performance dann auch noch akzeptabel oder ist die Auswirkung der Verfahren so groß, dass ich mit massivem Performancerückgang rechnen müsste?
Am Rande möchte ich noch bemerken, dass die Datenbankabstraktionsschicht nicht unbedingt ein Argument für Propel oder Doctrine ist – jedenfalls nicht, wenn es um den Austausch des zugrundeliegenden Datenbanksystems geht. Ich habe es bisher noch nicht erlebt, dass Jemand nach der Fertigstellung der Anwendung das DBS komplett austauschen wollte. Es ist aus meiner Sicht eher so, dass viel auf die besonderen Fähigkeiten eingegangen worden ist.
Derzeit versuche ich die Persistenz über das Data-Mapper-Pattern zu realisieren, aber ich frage mich natürlich „Hätte ich das nicht mit Propel schon längst fertig gehabt?“.
Ich finde, dass die Diskussion ob man ein Framework einsetzen soll, die dümmste Art der Zeitverschwendung ist, die es gibt.
Ich verstehe die Diskussion über ein Framework, ob es den Anforderungen eines Projektes gerecht wird oder nicht.
Stellt euch vor, ihr müsstet eine Desktopapplikation schreiben, da stellt sich ja auch nicht die Frage ob ihr ein Framework(MFC,QT,…) oder die winAPI verwendet. Oder ob ihr dazu ein fertiges Bestriebssystem verwenden sollt, oder dieses lieber selbst neu schreibt. Warum einen fertigen Rechner verwenden, wenn der mathematische Koprozessor einen Bug haben könnte.
Ein Framework ist ein Werkzeug, das zur Verfügung steht um einem die Arbeit zu erleichtern; Natürlich wird ein solches eingesetzt!
Oder geht eucher Mechaniker einen Hammer schmieden, wenn ihr kommt und sagt, dass ihr eine Delle im Auto habt.
Franz
11. PHP-Frameworks sind langsamer als andere Frameworks
Bei PHP wird für jeden Seitenaufruf das komplette Framework geladen, was total sinnlos ist. Django oder Ruby on Rails beispielsweise erstellen nur wenige Instanzen des Frameworks und verteilen die Requests darauf.
> Bei PHP wird für jeden Seitenaufruf das komplette Framework geladen, was total sinnlos ist.
Bei PHP wird für jeden Seitenaufruf das komplette Framework geladen, was total falsch ist.
Not invented here, not used here! Period!
Gruetzi,
> Bei PHP wird für jeden Seitenaufruf das komplette Framework geladen, was total falsch ist.
Dito
1) Das Framework will ich sehen, was automatisch alle Klassen läd.
Zend Framwork z.B Muss man sagen, welche Klassen man benötigt. Es sei denn man verwendet den Autoloader, der checkt das an den Instantiierungen. Also Schuss in den Ofen, oder?
Wie lange wurde es wohl dauern, jedesmal 50 MB auf der Startseite zu laden
2) Ja jedes Framework hat wohl seine Tücken. Dabei ist es egal ob Javascript wie dhtmlx oder EXTJS oder eben ZEND und Symphony.
Das ändert nichts daran, dass sie viele Funktionen Mitbringen, die man erst schreiben müsste.
[...] Eggert räumt mit Vorurteilen gegenüber PHP-Frameworks auf: 10 Gründe gegen den Einsatz von PHP Frameworks. Tolle Diskussionsgrundlage. « Sprechende Namen [...]
Ist ja alles schön und gut, aber es darf eines nicht vergessen werden: als ich 2000 mit PHP angefangen habe, gab es kein Zend Framework und auch kein CakePHP. Damals gabs auch kein Ruby on Rails.
Also habe ich mir eigene Sachen geschrieben und damit bereits grosse Applikationen entwickelt. Über die Jahre habe ich meine Ansätze natürlich verfeinert (und neu geschrieben), welchen Grund sollte ich haben, jetzt auf eines der “etablierten” Frameworks umzuwechseln? Und wenn ja, welches? Welches hat eine Codequalität und Handhabung, die meinen Ansprüchen genügt? Und wie hoch ist das Risiko, dass mir nachher in dem Framework das fehlt, was dessen Entwickler nicht vorhergesehen haben und wie schwierig wird es dann, diese fehlende Funktionalität zu erweitern und funktioniert diese dann noch nach einem Update?
Ich habe die Hoffnung, dass wird in den nächsten Jahren dank PHP 5.3 und Namespaces dem Punkt näher kommen, an dem man mit verschiedenen Packages verschiedener Projekte arbeiten kann, ohne sich mit Unsäglichkeiten wie Zend_schlag_mich_tot_Interface rumärgern zu müssen.
[ich möchte den PHP Entwickler sehen, der eine komplexe MVC-Komponente schneller schreibt,]
=> Es muss doch nicht immer eine komplexe MVC Architektur mit irgendeinem dummen Gedöns sein?
[Punkt 2. und 3. sind für beide Parteien unaussagekräftig]
[4. Das Framework XYZ ist völlig überladen, ich brauche nur 2 oder 3 der 40 Komponenten.]
=> Der Speicherverbrauch, der Traffik, die Rechenleistung………………………….???
[6. Ich kenne gerne den gesamten Programmcode im Detail, so dass ich lieber alles selber schreibe!]
=> Hier hast du nun wirklich Schwachsinn geschrieben. Wenn man etwas selbst schreibt, weiß man wie man was erweitern kann, kann sich leichter einarbeiten und weiß wie Komponenten zusammenarbeiten. Die unnützen overdress kann man sich doch wirklich sparen. Ich kann mich in Code deutlich leichter einarbeiten als wenn ich trotz Frameworkkenntnisse in xyz Ordnern rumgucke.
[8. Für das Framework gibt es dauernd neue Releases, bin ja nur noch am aktualisieren.]
=> Kommen wir nun zum größten Knackpunkt. Man sollte aktuelle Software nutzen und so ist das auch bei neuen Releases. Doch welcher Programmierer hat Lust bei großen Anwendungen alles auf neue Versionen anzupassen, wenn selbst Buchautoren dem bei kleineren Scripten nur schwer nachkommen.
[„Wie? Sie setzen kein PHP Framework ein und schreiben alles selbst? Zeit ist Geld! Und Sie sollten Ihre Zeit für mein Problem einsetzen und nicht das Rad neu erfinden! Ich kürze Ihnen das Budget!“]
Dann sagt man halt, dass sich der Kunde Anpassungskosten auf neue Releases spart und schon ist die Sache gegessen.
Ich halte Frameworks für zeitverschwendende Spielereien, mit hohem Sicherheitsrisikopotential, was sich schwer individuallisieren lässt. Für die langfristige Teamarbeit sind diese jedoch sicherlich zu überdenken.
Was könnt ihr auf meine angesprochenen Punkte gegenfeuern? Ich sage im vornherein schon, jeder zieht den Schuh so an, wie er ne haben möchte….
Hallo Zusammen,
Hier sieht man ganz klar, wie weit Ein Programmierer vom Opensourcegedanken weg sein kann. Er entwickelt unter PHP mit einer riesigen Gemeindschaft, in der Frameworks und Codesammlungen zum Alltag gehören und die Zusammenarbeit der Entwickler a) standardisieren soll und b) man schlich und einfach RAD (rapid app development) betreiben will.
Mit dieser Haltung ist es schlichtweg unmöglich guten sauberen Code zu schreiben, der Konventionen und Standards entspricht.
Man lernt erst den Umgang mit Code wenn man mit grossen Apps und Frameworks arbeitet.
Das Ganze ist meiner Meinung nach nicht anderes als eine Anpassungsschwierigkeit an die heutigen Programmiersituation in der es auf vernetztes Denken und Teamarbeit ankommt.
Und ich bin mir sicher. Er verwendet Opensource en mass und bedient sich jquery, prototype und der gleichen. Was auch nichts anderes ist.
auf jeden Fall eine gelungene Polarisation zu diesem Theme, was man an den Comments erkennen kann.
Mittax
Servus! Ich habe bisher ebenfalls auf selbstgeschriebene Frameworks zurückgegriffen, weil ich es Anfangs einfach nicht besser wusste und hatte auch die oben schon oft beschriebenen Probleme damit. Ich programmiere seit 2006 PHP im professionellen Bereich, zuvor eher als Hobby und stehe jetzt vor dem Problem, welches Framework für mich überhaupt in Frage kommt. Ich kann meinem Chef nicht einfach sagen, dass ich die nächsten 3 Monate erstmal nichts mehr produziere, da ich mich in verschiedene Frameworks einarbeiten muss um herauszufinden ob eines für uns geeignet ist. Ich hatte ja für meine Frameworks ebenfalls keine explizite Entwicklungszeit, sondern musste das ganze neben der eigentlichen Problemlösung immer wieder erweitern und anpassen, was natürlich eigentlich absolut untragbar ist. Das führte dann auch ganz klar zu Verzögerungen, welche ich auch mit den vorangegangenen Punkten begründet habe. Beim Anschlussprojekt hat es aber dann schon wieder niemanden interessiert und das gleiche Spiel ging von vorne los. Theorie und Praxis gehen in der Arbeitswelt halt einfach nicht immer zusammen, auch wenn man gute Argumente vorweisen kann.
Ich finde den Artikel wirklich gut und lesenswert, bin aber der Meinung dass man nicht zu schnell verurteilen sollte.
Eine ideale Ergänzung des Artikels wären Links, zu Seiten welche sich mit Frameworks und deren Anwendemöglichkeiten beschäftigen.
Gruß Spaff
Ich mache schon immer einen großen Bogen um Frameworks und alles, was sonst noch so an Vorgekautem gerade so hipp ist. Vorgekautes widerspricht nicht nur meinem Programmierstil, es widerspricht meinem ganzen Lebensstil. Es geht mir absolut gegen den Strich, Dinge, die andere gemacht haben, lediglich zusammenzupappen und das Resultat als meine eigene Arbeit zu verkaufen.
Außerdem gefallen mir die “Frameworks”, die speziell meine Arbeit betreffen (ich betrachte ein CMS als eine Art Framework) allesamt nicht. Während alle anderen nur am Aufrüsten sind, bin ich am Abrüsten. Mir ist das alles nicht einfach genug. Und was mir nicht einfach genug ist, ist dem Endanwender erst recht nicht einfach genug. Ich merke das immer dann, wenn Kunden von einem anderen CMS auf unseres umsteigen. Trotzdem bin ich nie zufrieden, weil ich immer wieder sehe, dass es noch einfacher geht – und da geht es schlichtweg nicht, wenn ich mich dabei mit Dingen umgebe, die ihrerseits immer komplexer werden.
Ein wesentlicher Punkt für mich ist auch der hohe Lerneffekt, wenn man etwas von Grund auf selber macht. Bei vielen Fragen in diversen Foren habe ich das Gefühl, dass sie nur an der Oberfläche kratzen und die Codeschnipsel aus den Antworten dann lediglich abtippen. Es “funzt” dann zwar meist, aber *warum* es nun funktioniert, bleibt dem Fragenden oft weiterhin verschlossen, und er wird dieselbe Frage irgendwann wieder stellen – freilich ohne sich dessen bewusst zu sein. Ich habe z. B. Pascal erst wirklich verstanden, als ich mit Assembler angefangen habe – und von diesem “Prinzipwissen” zehre ich heute noch.
Und was “Zeit ist Geld” betrifft: Ich mache da überhaupt kein Geheimnis draus, dass mein “Selbermach-Tick” den Endkunden *erstmal* mehr Geld kostet. Ich kann ihm aber mit einer kurzen “Livevorführung” zeigen, dass er danach selber Zeit spart – auch *seine* Zeit ist schließlich Geld. Außerdem hole ich die Zeit, die ich in die Weiterentwicklung des CMS stecke, dadurch wieder heraus, dass ich für damit ausgeführte Kundenprojekte allmählich immer weniger Zeit brauche. (Ferner kann ich auch immer mehr Sonderwünsche umsetzen.)
Und außerdem: wenn es für einen von uns nicht gut ist, ein Framework zu basteln, warum ist es dann für die Hersteller der hier zitierten Frameworks gut, ein solches zu basteln? Warum machen die das, wenn nicht aus dem selben Grunde, aus dem ich es mache?
André
@Spaff
Ich stimme dir nicht ganz überein. Es gibt sicher Framworkbetreiber die dies aus Geld machem, weil es halt Schulungen gibt. Aber ich denke ein Großteil davon möchte auch einfach Opensource etwas beitragen.
Ich denke nichtmal das deine Kunden mehr bezahlen müssen. Ich denke viel mehr, dass deine Kunden weniger zahlen oder der großen Gefahr einer Sicherheitslücke laufen. Klar man kannn MVC trennen und all dem Schmu, aber als ich letztens mal wieder ein Plugin entwicklet habe, merkte ich wie blöd es ist, die ganzen Variablen zu verfolgen usw. Nur weil alles in zich Framworks aufgeteilt war.
Entweder der Kunde updated sein Framework nicht => Sicherheit. Oder er lässt es aktuallisieren, wo gerade bei Zend momentan oft viele Anpassungen nötig sind. Folge: Der Kunde hat sehr hohe Folgekosten, für ein System was sich von der Performance nicht gerade positiv betrachten lässt-
@André:
Ich hoffe, Du musst niemals Mitarbeiter einstellen, die mit Deinem Code arbeiten müssen. Denn die müssten ja das Gegenteil von Deinem Lebenstil machen.
Entweder wirst Du Deinen Code immer selber pflegen oder aber Mitarbeiter finden müssen, die “Vorgekautes zusammenpappen”, denn nichts anderes ist es dann ja.
@Ralf: Dieser Fall ist zwar rein hypothetisch, aber bei so vielen Framework-Anhängern würde sich doch sicherlich jemand finden, der ganz heiß drauf ist, sich in ein Framework einzuarbeiten
André
@Timo: Apropos Update: ich hab das CMS so konzipiert, dass ich von möglichst möglichst wenigen technischen Voraussetzungen seitens der (unterschiedlichen) Webserver abhängig bin – oder anders gesagt: von möglichst wenig Fremdsoftware. Ich muss mich in Zukunft eigentlich nur mit eventuellen Änderungen an PHP auseinandersetzen, und da auch nur mit relativ wenigen Kernfunktionen. Wenn ich Frameworks einsetzen würde, müsste ich auch dort die Änderungen verfolgen und eventuell Anpassungen am CMS vornehmen. Aber wehe, ein Framework hört auf, PHP 4 zu unterstützen, dann kann ich das CMS bei einigen Bestandskunden nicht mehr updaten. Ich müsste dann mit zwei unterschiedlichen Versionen des CMS weitermachen oder auf das Framework-Update verzichten. Und genau das – also entweder ein Versionsdurcheinander oder technischen Stillstand – will ich vermeiden.
Eine zu große Abhängigkeit von Fremdsoftware kann ein Projekt irgendwann durchaus abwürgen. Ich hab das mit einer anderen Programmiersprache schonmal erlebt, da ging nach einem wichtigen Update gar nichts mehr. Da die Entwickler sich schon vorher lieber an neue Features statt an alte Bugs gemacht haben, hab ich es dann endgültig hingeschmissen. Seither setze ich auf offene und standardisierte Programmiersprachen, wo ich mich halbwegs darauf verlassen kann, dass nicht alle naselang irgendwas umgeschmissen wird und ich nicht immer wieder von vorn anfangen muss. Das würde analog auch für Frameworks gelten, aber wie gesagt meine ich, dass rein statistisch um so mehr Überarbeitungsbedarf auf mich zukommt, je mehr Fremdcode ich in einem Projekt habe.
Ein anderer Punkt ist, dass ich den Fremdcode konsequenterweise nicht anfassen dürfte, also keine eigenen Anpassungen vornehmen dürfte, da diese beim nächsten Update des Fremdcodes ja wieder überschrieben werden würden. Ich möchte mich andererseits aber auch nicht einschränken lassen, denn merke: nicht nur die Frameworks werden weiterentwickelt, sondern auch mein eigenes Projekt. Und da kann es durchaus sein, dass mein Projekt irgendwann Funktionalität erfordert, die das darin eingesetzte Framework nicht bietet. Da kann ich mich nicht hinsetzen und Däumchen drehen, bis das Framework auch soweit ist – wenn mein Wunschfeature denn überhaupt jemals darin landet (”Das braucht doch außer dir keine Sau”). Andersrum hasse ich es, Code in mein Programm zu schleppen, den ich dort nie brauchen werde.
Nee, das ist alles nicht mein Stil. Wenn es irgendwo hängt, wenn plötzlich jemand einen ganz speziellen Bedarf anmeldet, dann möchte ich das ohne Umschweife am Kragen packen können.
André
@André: ganz ohne Fremdcode ist unwahrscheinlich, es sei denn, Du hast Dir Deine eigene Implementierung von PHP geschrieben . Im Alltag greift man auf jeden Fall schon mal auf die mitgelieferten PHP-Funktionen zu, die zum Teil auf andere Fremdsoftware / Betriebssystemfunktionen aufbauen.
Gegen PHP-Fremdcode hätte ich im Prinzip auch nichts einzuwenden, ich unterscheide da zwischen einzelnen Bestandteilen und der Katze im Sack (=Framework), die viel Ballast mit bringt, Probleme bei Migration/Updates bereitet und mir mitunter eine bestimmte Vorgehensweise aufzwingt.
Wie ich schon sagte, mit PHP 5.3 ist mit der Zeit wohl eine bessere Modularität zu erwarten. Bei Java zieh ich mir mal eben JAI oder JUnit in den Classpath, es käme mir nicht ansatzweise in den Sinn, das selber machen zu wollen. Dafür kann ich aber meistens davon ausgehen, dass eine bestimmte Qualität gewahrt wird. PHP war da bislang halt ein wenig Wildwest.
Ich bin jetzt schon seit Jahren in der Softwareentwicklung und kenne diese Diskussion. Damals war es der RAD (rapid application development) Hype, wo ein Framework nach dem anderen auf den Markt kam und wieder verschwand, dann die ActiveX Controls die die Softwareentwicklung revolutionieren sollten, dann Frameworks wo man objektorientiert mit der Maus programierte und jetzt sind es Frameworks für Webservices.
Ich habe Zend jetzt die letzten Tage auch ausprobiert und gerade wieder von der Platte gelöscht. Einfache Funkionalität aufgeteilt in haufenweise Klassen und Dateien im Gegensatz zu der native Programmierung können mich nicht überzeugen. Ein innovatives Konzept zeichnet sich nicht dadurch aus dass man möglichst viele Klassen und Design Patterns zu benutzen versucht. Das ganze geht auf Kosten der Performance.
Das Klassenkonzept von PHP ist zwar gut, aber es sollte nicht übertrieben benutzt werden, weil dafür ist die Sprache nicht gemacht.
Auch der Autoloadingmechanismus des Frameworks. Was nutzt mir dieses Verfahren, wenn die Performance dermaßen in den Keller geht und die Benutzer meiner Internetseite den Gefallen an meinen Dienst verlieren. Eine einfache Datenbankabfrage und Rückgabe der Werte als HTML sind paar Zeilen Code und hat eine Latenzantwortzeit von wenigen Millisekunden. Der selbe Code in Zend hat mich ein mehrfaches der Zeit gebraucht, haufenweise Dateien und Ordner die angelegt werden musste um sämtlichen Konzepten und Design Patterns des Frameworks gerecht zu werden. Danach begann die Fehlersuche. Als ich dann den Test gemacht habe war ich schockiert, die Antwortzeit belief sich allein bei diesem Beispiel mit der Datenbank auf 5 Sekunden und mehr.
Ich habe jetzt viel mehr Code der schwerer zu warten ist, aufgeteilt in eine enorme Anzahl von Dateien wenn man die Bootstrap, index und Modeldateien dazu zählt und bekomme dafür einen Code der um ein vielfaches langsamer ist? Das mag zwar für den Entwickler in Ordnung sein, wenn der aber mal nicht mehr da ist und ich neue Leute brauch die das System weiter pflegen dann sieht es schlecht aus.
Frameworks nehmen nicht die Entwicklungsarbeit ab, wie man sich das ganze vorstellt. Ich muss da Timo recht geben, sie sind ein Balast und in meinen Augen auch absolut überflüssig, selbst wenn ich selbst alle mal ausprobieren in der Hoffnung dass mich eines irgendwann mal doch überzeugt.
Ich brauch für mein Projekt Tools die mir die Arbeit erleichtern, gleichzeitig aber auch den Code überschaubar machen und ich optimale Performance und Skalierbarkeit einsetzen kann.
Twitter hat sich glaub ich von Ruby on Rails distanziert, andere schmeissen auch ihre Frameworks raus oder probieren wieder neue aus. Ich finde man sollte erstmal den Nutzen und die Nachteile abwägen bevor man diese überhaupt einsetzt. Wenn ich einen High Performance Webservice plane der auch langfristig noch erweiter- und wartbar sein soll, dann steht für mich mein Projekt nur native PHP oder native Java zur Auswahl (eher jedoch PHP).
Frameworks ersetzen nicht den Programmierer. Sie bringen zwar gewisse Vorteile, aber auch eine Menge Nachteile. Da ist die Frage gerechtfertigt, ob die Suche nach einzelnen Komponenten die man im Internet findet nicht bei weitem die bessere Wahl ist, als sich von einem Framework abhängig zu machen. Der hohe Performanceverlust bei der Datenbankabfrage würde mich jetzt davon abhängigmachen aufs nächste Release zu warten in der Hoffnung dass dann eine verbesserte Implementierung kommt, oder mich selbst mit den fremden Code zu beschäftigen wo ich ehrlich gesagt keine Zeit für hab.
@PHPCode: Lese dir mal das hier durch http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 könnte dir gefallen.
@ Claus
Kann dir nur zustimmen. Habe wirklich zu 100% die Selben Erfahrungen gemacht und ich kann mit dem Zend Framework programmieren. Meine Meinung kommt also nicht zustande weil ich zu faul wäre mich da einzuarbeiten.
@Claus-Christoph
Du hast schon recht, genaugenommen ist PHP selbst auch ein Framework, ebenso wie jede andere Programmiersprache auch (insbesondere, wenn sie Standardbibliotheken mitbringen, wie z.B. die Unit CRT von Turbo Pascal oder die stdio von C). Ich finde eine Programmiersprache ist besonders dann gut gelungen, wenn sie mit möglichst wenigen, wohlgewählten Basisbefehlen auskommt, aus denen sich dann alle möglichen Spezialfälle ableiten lassen. In Frameworks in dem hier diskutierten Sinne ist dieser Vorgang des Ableitens von Spezialfällen aber bereits vollzogen. Das unterscheidet sie auf den ersten Blick vielleicht nur graduell von der Programmiersprache selbst, nach meinem Empfinden ist dieser Unterschied aber schon qualitativ – die Grenzziehung ist aber sicherlich Geschmackssache.
Ich hab übrigens tatsächlich schon Programmiersprachen selbst entwickelt (d.h., nachgebaut), u.a. einen Assembler und einige mehr oder weniger umfangreiche Interpreter.
André
@PHPCode
“Da ist die Frage gerechtfertigt, ob die Suche nach einzelnen Komponenten die man im Internet findet nicht bei weitem die bessere Wahl ist, als sich von einem Framework abhängig zu machen.”
Diese Frage ist definitiv gerechtfertigt. Ich habs mir erst kürzlich wieder selbst vor Augen geführt. Ich hatte zuvor einen (etwas speziellen) Onlineshop entwickelt, und stellte später fest, dass ich das Warenkorbmodul für andere Zwecke auch gut in anderen (Nicht-Shop-)Sites gebrauchen könnte. Also hab ich das Teil aus dem Gesamtcode herausoperiert, die Schnittstellen neutraler formuliert – und hinterher gemerkt, dass ich damit eigentlich nicht arbeiten möchte. Also habe ich die prinzipielle Funktionalität dieses “Frameworks” mit ganz wenigen Codezeilen und ganz wenigen Low-Level-Methoden nochmal programmiert – und dann hat es Spaß gemacht, das Ding hier und da mal eben schnell einzusetzen. Ich muss im konkreten Projekt dann zwar ein paar Zeilen Code schreiben, um dieses Modul eine Ebene höher für seinen konkreten Einatzzweck zu spezialisieren, aber das geht mir fix von der Hand, weil das alles sprechender Code ist. Abstrakte Schnittstellen hingegen “sprechen” nicht, jedenfalls “höre” ich nichts.
Will sagen: ich halte es für besser, sich die Funktionalität für ein Projekt nicht mit einem einzigen Alleskönner-Framework an Land zu ziehen, sondern mehrere kleine Low-Lewel-Module so zu kombinieren, dass sie in Summe genau das zur Verfügung stellen, was man konkret braucht.
Und diese Module kann man auch selbst programmieren. Man darf dabei nicht wieder den Fehler machen, mögliche Spezialfälle (vermeintlich) vorausschauend schon in diesem Modul lösen zu wollen, um sich Tipparbeit in den jeweiligen Projekten zu sparen. Das funktioniert nicht, das ist in diesem Artikel/den Kommentaren in bezug auf “Framework selber basteln” auch schon mehrfach gesagt worden. Spezialfälle abdecken zu wollen, funktioniert insbesondere dann nicht, wenn die Programmierer des Frameworks dieses nicht selbst exzessiv in unterschiedlichen Projekten einsetzen. Denn erst dann zeigt sich, ob die theoretischen Überlegungen in der Praxis auch tatsächlich ohne Verrenkungen umsetzbar sind. Ich hab das ja wie eingangs beschrieben gerade wieder selbst erlebt, dass Theorie und Praxis zwei sehr verschiedene Dinge sein können.
Es gibt noch etwas, was mich an Alleskönnern stört, und dieses Problem tritt gerade bei OOP besonders deutlich zutage. Wenn ich ein Alleskönner-Objekt für einen speziellen Einsatzzweck zurechtstutzen möchte, kann es sein, dass ich Methoden dieses Objektes überschreiben muss. In diesem Falle passieren zwei Dinge: im Framework “entsteht” plötzlich überflüssiger Code (nämlich die überschriebene Methode), und das Projekt enthält Code (die überschreibende Methode), der “geografisch” eigentlich ins Framework gehört (nämlich an die Stelle der überschriebenen Methode). Ich verändere also das Framework – nicht physisch, aber logisch (was für mich dasselbe ist). Dabei geht mir ein Stück weit die klare Trennung zwischen Projekt und Framework und damit die Übersichtlichkeit und intuitive Verständlichkeit verloren.
Ich empfinde es als eleganter und verständlicher, Low-Level-Methoden durch sone Art “Wrapper” auf ein höheres/spezielleres Level zu heben. Ich verändere oder verwerfe (überschreibe) die Original-Methoden also nicht, sondern kombiniere sie in unveränderter Form zu “High-Level”-Methoden. Das heißt, die Spezialisierung findet logisch und physisch da statt, wo sie hingehört, nämlich im speziellen Projekt. Anders gesagt, ich schiebe keine Funktionalität “rückwärts” ins Framework/Modul zurück, sondern ziehe vorn dort Funktionalität “vorwärts” ins Projekt.
Keine Ahnung, ob ich mich jetzt verständlich machen konnte, aber selbst wenn nicht, so macht es doch deutlich, wie unterschiedlich die Denk- und Programmierstile sein können und das nicht jedes Framework oder jedes Paradigma zu jedem passt. Ein Werkzeug muss auch Spaß machen, es muss perfekt in der Hand liegen, man muss es mit geschlossenen Augen virtuos benutzen können, es muss “perlen” wie bei einem guten Klavierspieler.
André
@André:
PHP ist kein Framework, man muss hier unterscheiden zwischen Framework und API/Klassenbibliothek (was Du ja auch später tust).
Eine API stellt eine bestimmte Funktionalität weitgehend isoliert bereit, in einer Klassenbibliothek mag es mehr Abhängigkeiten geben.
Ein Framework geht für gewöhnlich aber von einem bestimmten Kontext und einer bestimmten Vorgehensweise aus. Das ist gut, weil man sich dann bestimmte Dinge “automagisch” machen lassen kann. Ist aber schlecht, wenn man diesen Kontext gar nicht hat oder nur teilweise, denn dann fängt das Gekrampfe an.
In der Theorie sind Frameworks prima (=für Studenten), in der Praxis verschieben und potenzieren sind die Probleme (=für Chefentwickler).
Ein prominentes Beipsiel: yigg.de
@Christianx: Das halte ich für FALSCH. Es gibt genügend Projekte, die auf Frameworks, wie symfony, Zend Framework oder flow3 aufsetzen. Auch richtig große.
Ich würde gerade bei großen Projekten niemals auf ein FW verzichten wollen. Bei kleinen Dingen, würde ich es mir gründlich überlegen.
@Claus-Christoph
“Ist aber schlecht, wenn man diesen Kontext gar nicht hat oder nur teilweise, denn dann fängt das Gekrampfe an.”
Ja. Und je spezialisierter ein Modul ist, desto seltener/ungenauer passt es tendenziell zum Kontext.
@Timo
Mir ging es eigentlich nicht direkt um die Kosten, sondern darum, dass alleine die Auswahl eines evtl. geeigneten Frameworks, viel Zeit verschlingen würde und dann aber nicht sicher gestellt ist, dass die Verwendung des Frameworks für unsere Anwendungen tatsächlich möglich ist.
Nachdem ich die letzten Wochen mit dem Zend Framework verbracht habe muss ich sagen: Bevor ich mich in fremden Programmcode einarbeite, schreibe ich das schneller selbst.
Das ist sicherlich so nicht richtig, ich hab den Satz nur eingefügt um die Verbindung herzustellen, denn wenn es darum geht sein eigenes, auf die Erforderisse angepasstes Framework durch ein fremdes Framework zu ersetzen spielt Zeit die Hauptrolle. Momentan bleibt mir nichts anderes üprig, als mein eigenes Framework weiterhin einzusetzen, es wird wohl darauf hinauslaufen das Erlernen eines Frameworks auf den Feierabend zu verlegen, bis ich soweit bin, dass ich das Framework nach belieben an unsere Anforderungen anpassen kann… und das wird ne Weile dauern denke ich..
[...] 10 Gründe gegen den Einsatz von PHP Frameworks [...]
Hallo!
Geile Diskussion!
Durch diesen Blog habe ich jetzt einige andere Blickwinkel kennengelernt die mir vorher noch nicht in den Sinn gekommen sind.
Bin im Moment hin und her gerissen was ich nun machen soll. Framework ja oder nein? Ich muss sagen dass die Argumente gegen ein Framework bei mir irgendwie besser ziehen (liegt wohl an meiner skeptischen Grundeinstellung).
Warum ich kein FW will:
Ich will mich auch nicht abhängig machen und greife gerne auf meine eigenen einfach gestrickten Klassen zu (bis jetzt). Und ich denke auch dass mein spezieller Code für mein Spezielles Projekt von der Performance her schneller arbeitet als das FW (muss ich noch testen).
Ich werde mir das ZF mal etwas genauer anschauen, aber ich weiß nicht ob mir das jetzt zu lange dauert bis ich mich da eingearbeitet habe. Kann sein dass ich nach ein Paar Stunden merke dass meine Klassen übersichtlicher sind, und ich besser damit umgehen kann (so wirds wohl auch sein wenn ich mir nicht richtig die Zeit nehme alles zu testen).
Ich werd das Ergebnis meiner Entscheidung dann hier wieder Posten (dann könnt Ihr ja auch sehen wie lange ich geduldig war mich einzuarbeiten).
Danke schon mal an euch alle!
Ich verwende für die Entwicklung von PHP Anwendungen das Cakephp Framework. Ich bin begeistert. Die Entwicklung einer Website geht schnell von der Hand und dank der Konsole muss man sich um Standart funktionen wie das Hinzufügen, Bearbeiten oder Löschen von Datensätzen nicht mehr kümmern.
Aber Leute – ein gutes Framework ist Gold wert. Was will ich das Rad immer und immer wieder neu erfidnen? Bezahlt mir ja eh keiner… Auch kann ich sicher sein dass ein etabliertes Framework wohl weniger “untiefen” als mein eigener Code aufweist, da die Frameworks oft eingesetzt werden und allfällige Fehler über die Dauer wohl allesamt behoben werden.
Bezüglich Sicherheitslücken und updates: mach doch ein neues Geschäftsmodell draus, à la Service-Vetrag – “Sicherheitsupdate vom Framework alle quartale”
Hallo!
Hut ab für den Text!
Genau was ich gebraucht habe um mich doch für ein Framework zu entscheiden!
Ich selber wollte (bzw. habe) mein eigenes Framework geschrieben.
Einfach weil ich schon soviel Zeit in verschiedene Klassen und Funktionen gesteckt hatte.
Vor 2 Jahren lies ich es, aus Zeitgründen und andere Interessen, mit der Webentwicklung komplett sein – ebenso um einfach vom Wunsch des eigenen Frameworks los zu kommen und zu vergessen was ich gemacht habe und wo ich weiter tun wollte.
Jetzt will ich wieder einsteigen – gleich mit Web 2.0 – und ein vorhandenes Framwork nutzen.
Super – vielen Dank für diesen Beitrag!
Gruß,
Harry
Sehr interessantes Thema!
Ich versuche mich jedoch erstmal in OOP und Design Patterns bevor ich mich an PHP Frameworks begebe!
Sehr cooler Beitrag zu dem Thema!
RSS-Feed für Kommentare zu diesem Artikel. TrackBack-URL
Dieses Mal mit Artikeln zu den Themen Silverlight 3, MySQLDUmper, Doctrine.
Social Media (R)evolution. Weitere Themen sind noSQL, Crowdsourcing ...
PHP Frameworks optimal nutzen, Workshops für PHP Profis, Typo3 auf dem Weg zu Version 5.
Falls du Ahnung von PHP hast, dann mache es wie einige vor dir und melde dich bei uns (autor@phphatesme) als Co-Autor.