Kategorien
10 Gründe gegen den Einsatz von PHP Frameworks
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…
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 🙂
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.
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.
@Christianx: was meinste mit „yigg.de“ ?
@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..
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!
Hallo Nochmal,
hier die versprochene Antwort (siehe 6 Posts weiter oben).
Ihr habts geschafft und mich überzeugt! Nachdem ich mich nun sehr intensiv mit Frameworks beschäftigt habe, werde ich nun entgegen aller Skeptik mit dem Zend Framework arbeiten. Sicher wird es noch eine Weile dauern bis ich mich eingearbeitet habe, aber es wird voraussichtlich nicht so viel Zeit in Anspruch nehmen wie wenn ich alles selber entwickle. Außerdem habe ich das Ziel dem Framework etwas beizutragen wenn die Zeit dafür gekommen ist.
Nun noch eine Abschließende Frage/ Anmerkung:
Sehe ich das richtig dass das Zend Framework das am besten Entwickelte Framework ist?
Zumindest macht es den Eindruck als seien an dem Framework nur eingefleischte PHP Experten beteiligt.
Und die Kolumne von Ralf Eggert im PHP Magazin hat mich warscheinich endgültig zum Zend Framework gelenkt.
Danke!
Ich möchte etwas zu dieser – wie ich finde, sehr guten – Diskussion beitragen.
Ich kenne eine Firma, in der ein eigenes PHP-Framework im Einsatz ist. An diesem Beispiel zeigen sich die Probleme dieses Ansatzes. Man ist gestartet mit ein paar ambitionierten Programmierern und den besten Vorsätzen. Nun, einige Jahre später, ist der Stand wie folgt:
* Diese Code-Basis ist riesig, unüberschaubar und komplett undokumentiert.
* Das Framework ist voller Design-Fehler und kleinerer Bugs.
* Gewisse Erweiterungen sind aufgrund struktueller Probleme schlicht nicht umsetzbar.
* Die Performance ist unterirdisch.
* Der Wartungsaufwand ist gigantisch.
* Es gibt keinen Ausweg, denn das FW ist mit vielen produktiven Projekten verzahnt.
* Neue Kollegen finden keinen Zugang und sind daher maximal unproduktiv.
Natürlich kann man vieles davon auf die Entwickler dieses Frameworks schieben, und sagen: „Mir kann das nicht passieren.“, aber man sollte auch folgendes bedenken:
Mit den produktiven Einsätzen und den damit verbundenen Anpassungen fehlt irgendwann einfach die Zeit, die Code-Basis so zu pflegen, wie es wünschenswert wäre. Das geht in mehreren Stufen vonstatten. Als erstes fällt die Dokumentation weg, als zweites die Tests, zuletzt die Bugfixes. Am Ende schraubt man alles nur noch irgendwie zusammen, damit bloß der Release-Termin gehalten werden kann. Hätte man ein etabliertes Framework im Einsatz (Zend etc.), könnte man sich einfach man-power einkaufen, so hingegen ist das unmöglich.
Das spricht natürlich nicht generell gegen Eigenentwicklungen. André hat ja die Vorteile bereits gut dargestellt. Man sollte halt nur die Entwicklung und Wartung eines internen Frameworks klar als Projekt für sich sehen, dass permanent(!) neben allen anderm in der Firma läuft (und kostet), und dem die Aufmerksamkeit und Zeit zugestehen, die es braucht. Vor dem Hintergrund ist das dann schlicht eine Kosten-/Nutzenfrage. Ein Vorposter sagte, Frameworks seien etwas für die Theorie, nicht für die Praxis. Ich genau der gegenteiligen Meinung.
@Eric:
Die Probleme, die Du schilderst, sind universell. Verwendet man ein Framework, bekommt man die Probleme eben mit den eigenen Modulen und Anpassungen, und mit den verschiedenen Versionen des Frameworks. Da werkelt in Projekt X noch 2.1, in Projekt Z schon 3.4, jetzt soll man aber an Projekt X umfangreiche Änderungen vornehmen und kann sich nun entweder mit 2.1 rumquälen oder aufwändig auf 3.4 hochmigrieren. Dazu hat man dann die netten Probleme, wenn man an die im Framework nicht vorgesehenen Use Cases kommt.
Das Grundproblem heisst für mich „Framework“, egal ob fremdes oder eigenes. Meine Lösung heisst, dass ich soviel wie möglich mit einzeln stehenden Modulen abbilde, in denen ich noch keine Annahmen treffe, wie sie nachher verwendet werden.
Also pfui. Code eines Frameworks um die „require_once()“ befreien ist mal massiv Upgrade- und Maintainance Feindlich. Derartige Änderungen in einem 3rd Party Framework bedürfen einer entsprechenden Dokumentation im Projekt.
So oder so steigt damit auch die Komplexität der Maintenance. Also PFUI PFUI PFUI. Niemals vorschlagen sowas zu tun.
Gerade wenn Du sagst das es kein Problem ist ein Framework upzugraden. Was bei Zend z.b. nicht immer der Fall ist. Mal wird in Minor(!) Releases das Auflösen der Controllernamen geändert, ein anderes mal wird es zu PHP 5.3 kompatibel gemacht aber dabei auch gleich „#“ als gültiger Kommentardelimiter in Configfiles gestrichen.
Und wenn Du für Dein Projekt nicht eine Codecoverage von 90% oder mehr hast ist, wie jeder Entwickler in Großprojekten sicher schon gespürt hat, ein upgrade (des Frameworks) immer mit dem Risiko verbunden Funktionalitäten zu zerstören. Das ist halt immer das Risiko wenn Code verändert wird.
Also gerade beim ZendFramework muss man meiner Erfahrung nach auch bei Minor Releases gehörig aufpassen.
Also ich stehe vor einem ähnlichen Problem.
Nachdem es mich etwas genervt hat, daß man viele sachen wiederholt machen muss und das eigentlich strikt gegen „dont repeat yourself“ geht, dachte ich mir „ok, ich brauche dringend etwas , was zum beispiel nerviges form validieren vereinfacht.
Also bin ich auf unterschiedliche Frameworks und Artikel gestoßen, habe mir dann auch mal Zend runtergeladen und damit etwas „rumprobiert“ bzw. mal ein tutorial von ralf eggert durchgearbeitet.
Gleich das erste was mir aufgefallen ist – und was ich Zend sehr negativ ankreide : bei manchen versions aktualisierungen werden die namen geändert , beispiel für die Router komponente.
Und die hat von version 0.6 bis jetzt mindestens 2 neue namen bekommen.
Das sieht man sehr gut an dem Tutorial von ralf.
Das kann nicht im sinne des erfinders sein, daß nach jedem framework update, man seinen ganzen kram überarbeiten muss nur weil sich die namen ändern (für mich auch unverständlich wieso sowas überhaupt gemacht werden muss).
Für einsteiger halte ich frameworks schlichtweg zu komplex und unnötig kompliziert.
Ich möchte ja daß mir arbeit abgenommen wird durch ein framework, nicht das ich dadurch mehr entwicklungszeit verballere.
Klar muss man erstmal etwas Zeit investieren, um sich in das Framework einzuarbeiten.
Zend mag recht gut sein – auch ich werde mich damit noch näher beschäftigen..aber bisher war der umstieg eher eine qual (bisher hab ich schon teils MVC mäßig gearbeitet, allerdings auf selbstprogrammierten klassen + Smarty).
Noch was zu Punkt 6. „Ich kenne gerne den gesamten Programmcode im Detail, so dass ich lieber alles selber schreibe!“
Ja klar weiß ein Entwickler der seinen code selber geschrieben hat nicht jede Zeile im Detail, aber er weiß wo was gemacht wird, welche klassen wo ungefair eingebunden werden usw. – er kennt halt seine strukturen, da er sie selbst designed hat.
Wenn er einen fehler sieht, kann er meistens schon erahnen wo der fehler auftritt und ihn dementsprechend schnell beheben (zumindest weiß ich bei meinen projekten sofort wo ich suchen muss und hab den fehler auch recht schnell lokalisiert).
Bei einem framework hast du eine neue Fehlerkomponente dazubekommen, die du schwer kontrollieren kannst, und du wirst dir bestimmt ein paar mal die frage stellen: wo ist der fehler?
Ich denk unterm strich machen frameworks schon sinn – obs direkt Zend ist oder nicht sei mal dahingestellt (und ob ich letztenendes auch bei Zend bleiben werden sowieso ;)).
Einfach eins raussuchen und evaluieren. http://www.phpframeworks.com/
Zu 3.:
Linux ist auch Open Source, für jeden zugänglich. Aber irgendwie macht Windows was falsch, oder wieso ist das sonst so unsicher?
Guter Artikel…
Maybe the top page I read this month..
naturopathy course in India
Interessanter Blog-Eintrag: Der von „Blackflash“ angesprochene Punkt mit der persönlichen Vorliebe ist natürlich ebenso wichtig: Ich arbeite ebenfalls viel mit dem Zend Framework, jedoch gefallen mir dort einige Funktionen auch nicht: aber dann wird das halt anders gemacht als vom FW angeboten, nicht jedoch das komplette FW abgelehnt.
Es wird ja keiner gezwungen, jede Funktion des Frameworks zu nutzen, wenn es denn irgendwie möglich ist.
Aber in solch professionellen Frameworks wie Zend und co. (da stecken ja mehrere Personenjahre Entwicklungszeit drin) sind Funktionen vorhanden, die in professionellen Projekten einfach nicht fehlen sollten und deren Wartung oder sogar Entwicklung durch eine einzelne Person fast unmöglich ist (Email-Versand, PDF-Generierung, …).
Auch wenn das nicht zum Thema gehört:
Zitat Tim: „Linux ist auch Open Source, für jeden zugänglich. Aber irgendwie macht Windows was falsch, oder wieso ist das sonst so unsicher?“
Bei Windows gibt es gefühlt viel mehr Bugs als in Linux weil Windows einfach viel mehr genutzt wird. Die Chance, dass ein Bug entdeckt wird ist doch zehn mal so groß wenn zehn mal so viele Menschen die Software nutzen.
Zum Thema:
Ich arbeite generell ohne bekannte Frameworks (Das liegt vielleicht daran, dass ich mich noch nie richtig damit befasst habe). Wie schon jemand weiter oben geschrieben hat, so bin auch ich lieber unabhängig. Außerdem möchte ich immer genau wissen was in meinem Code wo und wie passiert. Ist so ein Bauchgefühl 🙂
🙂 echt VERDAMMT GUTER artikel. mir wären glaub ich keine 10 gründe eingefallen. das liegt aber auch daran dass ich überall frameworks nutze wo es nur geht.. php, css, javascript!
ich versuch gerade ein kostenloses online buch über effiziente webprogrammierung zu schreiben. da behandel ich unter anderem auch das thema frameworks was ich echt jedem programmierer ans herz legen kann. vielleicht möchtet ihr ja ein paar artikel lesen:
http://www.effiziente-webprogrammierung.info/programmierung/frameworks
Also zu 5.:
Ich selber nutze gerne das Symfony Framework mit Doctrine. Da gibt es auch durchaus Sachen die mir nicht gefallen oder mir schlichtweg fehlen. Deswegen habe ich verschiedene Zend Komponenten einfach mit in meinem Libary Verzeichnis,) liegen. Und wenn mir immernoch Komponenten fehlen, schreib ich einfach die neue Komponente. Das ist weniger Arbeit als wenn ich ein komplettes Framework schreiben müsste. Und damit fahre ich ganz gut, ich habe bisher noch nicht erlebt das mir eine Komponente fehlt.
Ein komplettes PHP Framework selbst zu schreiben, ohne Verwendung von 3rd party libraries, wäre natürlich ziemlicher Schwachsinn.
Ich finde es ist aber heutzutage sehr wohl möglich (und auch wirtschaftlich noch sinnvoll), eine eigene PHP Codebase mit grossem Framework-Charakter aufzubauen, ohne dabei aber jegliche Low-Level Dinge selbst zu schreiben.
Ich persönlich habe vor kurzem die Entscheidung getroffen, so ein Framework zu bauen, allerdings natürlich nicht nur für ein einziges Projekt. Aufbauend auf phing, propel, lucene, swiftmailer, diversen anderen Zend- und Pear Komponenten ist dann innerhalb kürzester Zeit ein kleines MVC Framework entstanden, wo die Dinge organisatorisch eben genauso sind wie ich sie haben will. Diesen „Wohlfühlfaktor“ darf man halt nun auch wieder nicht vernachlässigen!
Verglichen mit dem Zeitaufwand um Symfony, Cake oder Typo3 zu lernen bin ich hier definitiv schneller zu einem Ergebnis gekommen. Dazu muss man aber anmerken, und das ist ja eigentlich mein Punkt jetzt, dass ich bereits vorher schon Erfahrung mit Symfony u.a. Frameworks hatte. Ich habe mir also die für mich besten Dinge einfach rausgepickt, viele Design-Elemente sind von Symfony in mein eigenes Framework eingeflossen, und ich kann im „Notfall“ jederzeit wieder zu Symfony oder Zend zurück. Ich bin lediglich mit manchen Entscheidungen bei Zend und Symfony nicht mehr einverstanden. Insbesondere hat mich bei Symfony der Sprung von 1.0 auf 1.2 doch ziemlich verwirrt. Aber das war eben offensichtlich eine Zeit wo PHP Frameworks erst aufkamen bzw. erst schön langsam stabil wurden.
[[ … Back to the cake. Well, IMPRESSIVE. This framework saves you lots of work — most functions you need everyday are already there and the documentation called „Cookbook“ is also quite complete and easy to understand. The API is not very complicated, so learning this framework is definitely faster than writing your own framework. (For the German readers: read this article). … ]]
http://blog.coldtobi.de/1_coldtobis_blog/archive/301_cakephp_baking_a_application_in_minutes.html
coldtobi
Ich finde den Artikel sehr gut geschrieben, hat mich selbst auch teilweise zum umdenken im umgang mit Frameworks gebracht. Zu erwähnen sei das die Einarbeitungszeit doch sehr Zeit intensiv ist, was viele (mich eingeschlossen) abneigt sich einzuarbeiten.
Ich habe mich schon verschiedenen PHP Frameworks auseinandergesetzt und habe die Tutorials durchgelesen, worin einfache Blogs erstellt wurden. Zu dem Zeitpunkt war ich begeistert. Als ich aber mein erstes Projekt damit aufbauen wollte merkte ich, dass ich lauter Workarounds bräuchte um einigermaßen mit einer komplex verschachtelten Datenbank zu arbeiten.
Schon war die Freude an dem Framework vorbei und ich habe auf meine eigenen Klassen zurückgegriffen.
Das Problem der Frameworks wie ZEND ist das bei den meisten Framework Projekten in der Definition bereits Fehler gemacht werden. Viel zu oft generieren Frameworks fertigen html Code wo lediglich nur noch beschrieben werden muss, wie und welche Daten man aus der Datenbank darstellen möchte, das Ganze mit bissl Javascript verschandet. Und genau das stört mich allgemein.
Meiner Empfindung nach ist der Ansatz der meisten Frameworks der falsche. Sicherlich erleichtern die großen vorhandenen Frameworks dem Entwickler die Arbeit, sparen doppeltes Tippen und wenn man es richtig einsetzt sparen diese auch Zeit und Codezeilen.
In der heutigen Zeit müssen wir uns gerade im Web mit einer Vielzahl an Datenquellen auseinandersetzten. Einheitlichkeit gibt es da nicht, egal ob JSON, XML, MYSQL, CSV, PostGres, MSSQL, Oracle, Caché… die Liste ist endlos. In wirklich komplexen Web Projekten müssen oft viele dieser Datenquellen gemischt werden, auf einheitliche Zeichencodierungen gebracht und anschließend gefiltert und mit anderen Daten aus ebenso unterschiedlichen Datenquellen angereichert werden. Teilweise müssen dann auf den unterschiedlichen Elementen noch Rechte vergeben werden. Und genau das ist das Feature was mir fehlt.
Hierzu fehlt jeglicher Ansatz und in diesem Content wird jeder Einsatz bestehender Frameworks zum Performancekiller und fordert eine Eigenentwicklung, die dann meist nicht mehr OpenSource bereit gestellt werden kann, da sie sehr oft zweistellige Mannjahre Entwicklungszeit verursachen….
Für unsere Seite bin ich gerade am abwägen, ob wir auf ein Framework umsteigen, oder doch unsere eigene Lösung bestehen lassen. Da wir lediglich die eine Seite betreiben ist eher die Performance, sowie die Skalierbarkeit von Frameworks interessant. Hierfür vermisse ich in diesem Beitrag leider
Vergleiche zu einer eigenen schlanken Lösung, die nicht so viel Overhead hat.
Ich habe die Erfahrung gemacht, das im Laufe eines Projekts der Kunde stehts mit der Frage kommt:“Kann mann nicht noch dies oder das machen“. Das können recht ausgefallene Wünsche sein. Wenn das Framework nicht von mir geschrieben ist, käme ich immer in die Verlegenheit zu sagen:“Ich weiß es nicht“. Oft kommt es dann auch vor, dass ich zur Umsetzung dieses Zusatzwunschen sehr viel in Foren recherchieren muss und mich durch viel Code arbeiten muss um eine aus Kundensicht Kleinigkeit umzusetzten.
Ist das Framework von mir kann ich sofort sage „Ja, geht. Dauert so und so lange…“. Und dann weiß ich sofort wo ich überall anpacken muss.
Lustiger Artikel 🙂
Der einzige -nicht erwaehnte- Grund: eine eigens geschriebene Anwendung mit eigenem „framework“ KANN schneller in der Code-Ausfuehrung sein!
Man nehme Facebook z.B., die schreiben auch alles selber, eben aus dem vermuteten Grund.
Natuerlich bieten Frameworks wie ZF cache-Funktionalitaeten an, um das Ganze schneller zu machen.
Jedoch ueberwiegen fuer mich auch die Vorteile ein Framework wie ZF zu nutzen, denn man braucht nicht mehr soviel zu erfinden und vor allem zu debuggen!
Wenn erstmal die Lernkurve ueberschritten worden ist, stellt man fest, dass man viel schneller als ohne weiterkommt. Vor allem hat man das Argument bei dem Kunden, dass man ihm eine „portable“ Anwendung geliefert hat.
Ausserdem kann man endlich standarisierte Patterns anwenden, unit tests und facebook-logins usw. integrieren ohne jedesmal das Rad neu zu erfinden.
Gedanken zum Framework (FW).
Fast alle Programmierer (je unerfahrener desto mehr) neigen dazu, eine eierlegende-wollmilchsau zu implementieren. Ich habe schon Funktionen (Methoden) gelesen (und versucht zu verstehen) mit mehr als 12 Parametern (Argumenten). Bei den OOP Freeks bitte ich um Entschuldigung, dass im Weiteren die Bezeichnung und nicht verwende.
Das Pattern MVC ist ein Entwurfsmuster zur Strukturierung von Software-Entwicklung in die drei Einheiten: Datenmodell, Präsentation und Programmsteuerung.
Dazu folgendes:
Model: Speziell FW-Funktionen für Datenbank-Zugriffe (Modell) mit JOINs sind sie nur bedingt brauchbar. Man kann aber dabei viel lernen, wenn man die Source durcharbeitet.
Controll: In der Regel FW-ungeeignet.
View: Hier kann man eine Menge Geld und Zeit sparen (das beste Beispiel -> jQuery).
Ein Streit bezüglich ‚Pro und Contra FW‘ ist nur dann sinnvoll, wenn diese 3 Ebenen getrennt werden.
Ein Bespiel aus der Architektur: Wie soll ein Gebäude aussehen, welche und wie groß Türen und Fenster sollen sein, wie Baut man ein Konzerthalle oder eine Straßenunterführung?
Das man selber keine Ziegel brennt, ist banal. Ob man Fenster und Türen in Standardgröße verwendet, ist fraglich.
Je komplexer eine Funktionalität ist, um so weniger ist sie geeignet, eine Baustein zu Bauen, der für alle brauchbar zu sein soll.
Werft mal einen Blick auf das Yii-Framework. Nach meinen Erfahrungen mit dem Zend Framework ist das eine Offenbarung.
Ein etwas anderer Blickwinkel: Gerade in der Zusammenarbeit mit reinen Frontend-lern sind „große“ Frameworks tatsächlich ein wirtschaftlich messbares Hindernis, hier haben sich zum Glück MicroFrameworks etabliert. Ich hab Leute beim Versuch Zend1 für ein vorranging JS-lastiges Projekt zu nutzen verzweifeln sehen. Simple Dinge wie eine Form zu schreiben (was 30 Sekunden kostet) werden durch das Framework oft behindert, und ich glaube auch daß die Framework-Autoren mit ihrem krassen Focus auf PHP und zT keinerlei Ahnung von JS/Frontend da oft unwissend harte Barrieren einbauen. Es ist mir sowieso schleierhaft warum PHP-Frameworks so oft ganz massiv in die Views und deren Generierung eingreifen, simples natives basic-HTML (in für Frontendler verständlichem Code) würde SEHR viel helfen. Ich stimme dem Artikel voll zu, ABER wir sehen das Ganze eben aus reiner PHPler-Sicht. Die Frontendler verbringen einen Großteil ihrer Zeit damit alles „für das Framework umzubauen“. Da sollte man ansetzen.
Die Gründe sind doch für einen Einsatz auch nur herbei gezogen..
Code wo niemand kennt ist immer sicherer als open source oder lasst du deine Haustüre auch dauernd auf?
Zudem muss ich sagen wenn du in10jahren keine wirkliche Ansammlung an Funktionen erstellt hast die du noch in 10jahren nutzen kannst, will ich besser den code nicht sehen und ein framework selbst für ein Gästebuch angebracht
Die Argumente FÜR die Verwendung von Frameworks lassen sich doch wirklich einfach finden – es sind Varianten von:
– weil es [„modern ist“|“doch alle verwenden“]
– weil es mir erspart, code zu schreiben
…
weil ich es [„so am besten“|“nur so“] kann
Im Grunde sind das die gleichen Argumente, mit denen noch vor einigen Jahren die Verwendung von „register_globals=on“ begründet wurde. Heute begründet man mit eben diesen Argumenten, warum „register_globals=on“ vermieden werden soll. Sieht man etwas genauer hin, war „register_globals=on“ schon immer eine Schnapsidee, auch als alle „Experten“ das für eine gute Lösung hielten.
PHP-Frameworks gibt es wie Sand am Meer. Jedes einzelne beweist eigentlich bereits, dass es Projekte gibt, wo die übrigen aus irgendeinem Grund unzulänglich waren. Und die Tatsache, dass es einen Namen hat, zeigt, dass es eine gewisse Community gibt, die diese Ansicht teilt. Wenn Zend alle Probleme löst, dann frage ich mich, was die Leute von Symfony eigentlich geritten hat … oder die bei phalcon.
Ja, Frameworks ersparen mir, Code zu schreiben.
Und Rouladen aus der Dose ersparen mir, diese selbst zu kochen (wo möglich würde sich herausstellen, dass ich gar nicht, oder jedenfalls nicht wirklich gut, kochen kann).
Wenn ich behaupte, Koch zu sein, werde ich dafür bezahlt, selbst zu kochen und nicht dafür, mich mit dem Angebot im Supermarkt und in der Bedienung von Microwellen auszukennen. Und als Entwickler werde ich eben dafür bezahlt, selbst Code zu schreiben.
Frameworks sind wie Fast-Food aus dem Supermarkt: es geht schnell, ist billig. Und für wenig Geld lässt sich das Projekt eben auch nur mit einem Framework wuppen. Aber für das Dinner mit meiner Liebsten kaufe ich die Zutaten lieber einzeln auf dem Wochenmarkt (vorausgesetzt, ich kann kochen), oder lade sie in ein Restaurant ein, wo die Rouladen nicht aus der Dose serviert werden.
Was nicht vergessen werden darf:
Auch viele etablierte Opensource-Frameworks haben einst als „eigenes“ Framework begonnen. Dann wurden sie veröffentlicht und von einer Community weiterentwickelt. Klar, die meisten schaffen es nie, zu einem Top-Framework. Einige halt aber doch… und um die wäre es ewig schade, wenn sie der ursprüngliche Programmierer nicht begonnen hätte!
Hi, ich kann für PHP Entwickler die nicht zufrieden mit Frameworks sind, das MVC4PHP Framework (http://mvc4php.com) Empfehlen um eigene Framework zu entwickeln.
oop, mvc usw. ist wie spielen mit lego.
aus lego kannst du bauen was du willst…
klar gibt es menschen die selber gerne lego steine machen möchte.
mir macht es jedoch mehr spaß mit diesen bausteine und teilchen, zu spielen.
Die Diskussionen sind doch hier für die Tonne Sicherheitslücken hat alles egal ob Zend oder ein eigenes. Wie schnell das gelöst wird hängt von der Fähigkeit ab, zum anderen ist es relativ nervig wenn ,an Lücken fixt,man mein Update macht und die Lücke ist wieder drin. Da muss man erstmal wieder Zeit opfern für die com.
Lustig ist noch wenn das Framework missbraucht wird von den eigenen entwickelten Code, hier fehlt Grundwissen von Fachpersonal. Dadurch wird so eine Webanwendung erst recht zu einen gewaltigen Problem.
Ein Framework kann niemals den Mist absichern den man selbst verzapft daher ist das einfach nur falsch.
Und warum ein eigenes Framework schlechter sein soll oder unsicherer ist Käse. Wenn man weiß was man macht funktioniert das ganze genauso gut sogar besser mit weit aus weniger Aufwand.
Einige Schreiben auch hier man versteht nach 2jahren sein eigenen programmierstil nicht mehr, deswegen baut man auf ein Framework. Schon lustig wenn man seine eigene Programmier Logik nicht mehr versteht ,daher sollte man vll die Sprache von Grund auf neu erlernen.dieser Murks kann auch kein Framework übersichtlicher gestalten.
Was bringt jemanden eine Doku vfür inen Framework was wenn man selbst keine Doku für seine eigene Scripte erstellt.das alles ist eigentlich Standart.
Die beschriebenen Gründe sind gut dargestellt, dein Text locker zu lesen, gefällt mir. Für größere Projekte ist ein Framework Pflicht.
Es gibt aber doch noch zwei Gründe für ein eigenes Framework:
1. wenn dieses aus bereits vorher getesteten Komponenten besteht (also im Prinzip auch ein Framework beinhalten könnte), mit Composer installiert werden kann, wenn die Aufgaben dafür im überschaubaren Bereich liegen.
2. Für ganz ganz einfache HTML-Seitendarstellungen ohne Funktionalität reicht es bereits, selbst ein wenig was mit Templating zu machen und man ist sich hinterher sehr sicher, dass solche Simple-Umsetzungen sehr lange laufen werden ohne Updates und Weiterverfolgung. Aber mann muss natürlich HMTL, CSS und Javascript beherrschen.