Angenommen, Sie möchten sich einen Tisch für Ihr Wohnzimmer selber bauen. Sie möchten nicht viel Zeit mit dem Bau des Tisches anfagen – Sie möchten ihn später nur benutzen.
Natürlich hatten Sie schon oft eine Säge und einen Schraubendreher in der Hand. Sie wissen, was zu tun ist. Sie überlegen, ein spezielles Werkzeug einzusetzen, von dem gesagt wird, dass Sie damit effizienter arbeiten können. Die Beherrschung des Werkzeuges hätte den Vorteil, dass Sie es auch für andere Arbeiten im Haus benutzen könnten. Aber das Werkzeug ist so umfangreich und so speziell, dass Sie es wirklich erst Stück für Stück erlernen müssen. Später können Sie sich mit einem Herstellerzertifikat damit brüsten, dieses Werkzeug zu benutzen. Es geht sogar so weit, dass spezielle Schulungen für das Werkzeug angeboten werden. Außerdem können Sie das Werkzeug nur dann benutzen, wenn Ihr Wohnzimmer spezielle Anforderungen erfüllt.
“Warum sollte ich ein Werkzeug nutzen, dass viel Einarbeitungszeit verlangt? Ich möchte doch einfach nur einen Tisch bauen!” werden Sie sich spätestens jetzt fragen: “Ich brauche lediglich etwas Holz, eine Säge, einen Akkubohrer / Akkuschrauber und etwas Befestigungsmaterial.”
Und damit haben Sie Recht. Haben Sie jemals gehört, dass das Erlernen von einem tollen Werkzeug (das spezielle Anforderungen stellt) effizienter ist als das Benutzen von bekannten Werkzeugen, die das gleiche Ergebnis erbringen?
Ähnlich verhält es sich auch mit großen Frameworks wie dem Zend Framework. Versteht mich nicht falsch: Ich habe nichts gegen (PHP-)Frameworks – im Gegenteil, ich nutze sie selber und möchte sie besonders bei umfangreichen Projekten nicht mehr missen.
Allerdings finde ich, dass
- man den logischen und strukturellen Aufbau einer Website (In Frameworks gerne ‘Apps’ genannt) auch übertreiben kann und
- dass die Einarbeitung und der Einsatz eines solch großen Frameworks oft in keinem Verhältnis zum Projekt steht.
Hier ein Auszug aus der Wikipedia über Web-Frameworks:
Die Fähigkeiten eines Webframeworks sind darauf ausgelegt, sehr schnell Ergebnisse zu erzielen und lauffähige Webanwendungen zu erstellen.
So oder so ähnlich hätte ich ein Web-Framework auch beschrieben. Das Problem: Es ist eben nicht “so ohne weiteres” möglich, mit Zend & Co. eine Applikation zu erstellen!
Ich nehme einfach mal das Zend Framework stellvertretend als Beispiel für ein “großes Framework mit solider Architektur”. Ich möchte noch einmal klarstellen, dass ich das Zend Framework nicht schlecht machen möchte! Ich möchte nur aufzeigen, warum der Einsatz eines solchen Frameworks oft unnötig ist! Ich gehe fest von der gewagten These aus, dass für versierte PHP-Coder die Entwicklung eines eigenen Frameworks genauso viel Zeit in Anspruch nimmt wie das Erlernen und Meistern vom Zend Framework. Das eigens entwickelte Framework hat nicht nur den Vorteil, dass man eine ganze Menge lernt, sondern auch dass der Overhead des Frameworks nur so hoch ist, wie er sein muss.
Framework ist nicht gleich Framework
Oft wird an dieser Stelle argumentiert, dass das andere Frameworks wie das .NET-Framework oder jQuery so umfangreich ist, dass man nur schwer darauf verzichten kann oder dass es für eine Einzelperson unmöglich wäre, es “nachzuschreiben”. Das ist teilweise korrekt; es trifft auf viele Frameworks zu. Beispiel jQuery: Das Problem an der Nutzung von “rohem” JavaScript ist, dass nicht jeder Browser es identisch verarbeitet. Es gibt so viele Falltüren und Situationen, bei denen das Script im Browser X funktioniert, im Browser Y aber eine Fehlermeldung hervorwirft. Es kostet ungemein viel Zeit, all diese Unterschiede zu entdecken und Workarounds zu entwerfen. JavaScript-Frameworks wie jQuery nehmen dem Entwickler diese Arbeit ab.
Bei PHP muss man sich nicht wirklich Gedanken um Workarounds machen. Natürlich gibt es betriebssystemspezifische Unterschiede, beispielsweise im Dateisystem. Aber dafür bietet PHP eigene Funktionen und Konstanten, um diese Unterschiede auszumerzen. Dafür brauch niemand eine Klasse.
Ich möchte an dieser Stelle keineswegs eine allgemeine Diskussion über PHP-Frameworks lostreten. Ein Framework für PHP ist aber nicht mit dem Zweck eines Framework für eine andere (Programmier)sprachen zu vergleichen. Ein PHP-Framework sollte einem Benutzer im wesentlichen nur zwei Aufgaben erleichtern (die in gewisser Weise auch zusammen hängen):
- URL-Routing
- (H)MVC-Implementation
Alles andere wie zum Beispiel Caching, Datenbankzugriff, Internationalisierung oder Formularverwaltung werden immer von einzelnen Klassen übernommen. Das Zusammenfügen dieser Klassen ist keineswegs Sinn und Zweck eines Frameworks. Dazu dient die Objektorienterte Programmierung an sich.
Wulstige Code-Gebilde
Bei Zend führt diese extreme Abstraktion zu unhandlichen, wulstigen Code-Gebilden. Anstatt sich mit ineinander verschachtelten Arrays und zu definierenden Namespaces herumzuprügeln, reicht oft ganz normaler Code. Hier einmal ein Beispiel zur Implementation eines einfachen HTML-Formulares mit einem Knopf und zwei Textfeldern. Es ist direkt aus der offiziellen Dokumentation und benötigt über vierzig Zeilen Code:
class My_Form_Login extends Zend_Form
{
public function init()
{
$username = new Zend_Form_Element_Text('username');
$username->class = 'formtext';
$username->setLabel('Username:')
->setDecorators(array(
array('ViewHelper',
array('helper' => 'formText')),
array('Label',
array('class' => 'label'))
));
$password = new Zend_Form_Element_Password('password');
$password->class = 'formtext';
$password->setLabel('Password:')
->setDecorators(array(
array('ViewHelper',
array('helper' => 'formPassword')),
array('Label',
array('class' => 'label'))
));
$submit = new Zend_Form_Element_Submit('login');
$submit->class = 'formsubmit';
$submit->setValue('Login')
->setDecorators(array(
array('ViewHelper',
array('helper' => 'formSubmit'))
));
$this->addElements(array(
$username,
$password,
$submit
));
$this->setDecorators(array(
'FormElements',
'Fieldset',
'Form'
));
}
// [...]
$form = new My_Form_Login();
}
Und jetzt die Realisierung des Formulares ohne Zend_Form, sondern direkt in HTML:
<form action="" method="post"> <label for="username">Username:</label> <input type="text" class="formtext" name="username" /> <label for="password">Password:</label> <input type="text" class="formtext" name="password" /> <input type="submit" name="login" class="formsubmit" value="Login" /> </form>
Abgesehen davon, dass “rohes” HTML immer schneller ist als (objektorientiertes) PHP: Es wurde nur ein Viertel der Zeilen benötigt und es ist für jeden Menschen besser zu lesen.
“Man ist doch nicht auf die Nutzung einer solchen Formularklasse angewiesen” höre ich dann oft. Aber wenn das wirklich das einzige Argument ist, dann frage ich mich, ob man dann wirklich ein Framework benötigt dass solche Lösungen anbietet.
Man benötigt eben nicht für jedes Webseiten-Element einen Helper, eine Klasse oder eine Library (nennt wie ihr es wollt). Je logischer und struktureller ein (PHP-)Framework wird, desto mehr Overhead bahnt sich an. Das ist jedoch nicht unbedingt gleichbedeutend mit einem Performanceverlust.
Und die Perfomance?
Es ist schwer zu beurteilen, ob bei der Masse an Klassen die Performance wirklich signifikant leidet. Nahezu allen Webframework-Vergleichen darf man sowieso nicht trauen, weil die Geschwindigkeit je nach Einsatzzweck immer eine andere ist und ein einfacher Speedtest eines “Hello World”-Projektes repräsentiert nicht die Gesamtperformance eines Frameworks – diese wird sich wahrscheinlich nie real messen, genausowenig wie man den Spritverbrauch von PKW’s vorhersagen kann.
Es wäre aber nachvollziehbar, wenn das Zend Framework bei aufwendigen Projekten (Webshop, Enterprise-Interface etc) im Vergleich zu anderen Frameworks schneller ist als bei “Hello-World”-Performancevergleichen. Dies wiederrum bedeutet, dass der Einsatz von Zend & Co. bei kleinen Projekten unnötig, ja sogar nachteilig sein könnte.
Und jetzt das Argument vieler Nutzer: “Tausende / Millionen Nutzer können sich nicht irren!”.
Doch, sie können! Denn mir fallen nur wenige (öffentliche) Webseiten ein, die aufgrund Ihrer Komplexität den Einsatz eines so mächtigen Frameworks rechtfertigen.Warum fällt also so oft das Wort “Zend”, wenn es in Foren um die Frage nach einem geeigneten Framework geht?
- Oft wird ein Framework empfohlen, von dem man am meisten “gehört” hat. Viele Empfehlungen sind daher nicht auf eigene Erkenntnisse zurückzuführen.
- Der Einsatz vom komplexen PHP-Frameworks erfordert ein hohes Maß an Wissen über objektorientiertes PHP sowie über Software-Architekturmuster. Viele Personen, die das komplexeste Framework empfehlen, möchten sich mit (meist nicht vorhandenem) Wissen brüsten.
- Falsches Wissen über Zend Framework mangels Unerfahrenheit, so kursieren diverse Thesen im Internet, das Zend Framework sei das schnellste, da es direkt von PHP-Entwicklern kommt.
- Und sicherlich gibt es auch den Bruchteil der Forenuser, die tatsächlich an mehreren Enterprise-Webapplikationen mit dem Zend Framework gearbeitet haben und deren Empfehlung in diesem Fall gerechtfertigt ist.
Ich möchte Interessenten einfach nur davor bewahren, sich von den komplexen Frameworks blenden zu lassen und sie dazu animieren, ein eigenes Framework zu entwickeln. Oder für den Anfang ein Framework zu wählen, dass eine sanfte Lernkurve erfordert – zum Beispiel CodeIgniter.
Natürlich ist das Geschmackssache: Aber für eine Webseite für den Bäcker um die Ecke benötigt man maximal ein schlankes Framework, dass nur die gröbsten Aufgaben übernimmt. Aber es soll ja auch Menschen geben, die mit dem Porsche zum Brötchen kaufen fahren.
Hmm, naja, das was bspw. unter “Wulstige Code-Gebilde” beschrieben ist, hört genau dort auf, wo Frameworks interessant werden – bei der strukturierten Verarbeitung wiederkehrender Prinzipien. Denken wir nur einen Schritt weiter – zum Affenformular, vielleicht auch mit weniger trivialen Elementen als Inputfeldern, wird die Umsetzung nämlich sehr schnell redundant, unübersichtlich und pflegeaufwändig. Vielleicht kommt HTML dann immer noch mit weniger Zeilen aus – übersichtlich ist das aber nicht mehr. Ganz zu schweigen von der Anbindung externer Datenverarbeitung an die jeweiligen Eingabeelemente.
Sicher kann man jetzt argumentieren, dass das auch gute Klassen/Libraries leisten können – leistungsfähige PHP Mailer sind das beste Beispiel dafür. Nur schleicht sich dabei auch ein bisschen Gefühl vom Anfang des Jahrtausends ein – als man sich seine Lösungen im Netz aus Individuallösungen zusammenkopierte – hier ein Bildwechsel über Javascript, dort ein Gästebuch, das man aber nur mäßig ins eigene Layout eingepasst bekam.
Ein Framework kann aber noch mehr. Zum einen bietet es im Ggs. zu Insellösungen saubere Strukturen, wiederverwendbare (gemeinsame) Basisklassen, einen besseren Schutz vor Namensraum- und Parameterkollisionen. Allen gemeinsam scheint die Stärke des FW eher in der Rolle der Konvention zu liegen. Wie Code-Konventionen zu lesbarem Quellcode führen, führen Frameworks zu begreifbarer Applikationsstruktur, intuitiver physischer Strukturierung etc. Mit allen Vorteilen die daraus erwachen – Modularisierung von Programmkomponenten, automatische Installer, Plugintechnologien, Austauschbarkeit von Funktionalität (alles automatisierbar und auf physischer Ebene). Gerade Anfänger haben vor der Planung großer Applikationen das Problem, dass sie nicht wissen, wie sie anfangen sollen, weil von Pluginprinzip, Ordnerstrukturen etc. alles miteinander verwoben ist und die ersten Entscheidungen maßgeblich die spätere Anwendungsstruktur bestimmen. Machen wir uns nichts vor – eine gut durchdachte Individuallösung wird immer besser sein als ein Framework – die Stärke liegt aber gerade darin, die Freiheit zu beschneiden und eine Ideallinie vorzudefinieren. Wenn das Framework dann passend zum Anwendungsfall gewählt ist, bildet es eine solide Basis, um darauf aufbauen zu können. Mehr nicht, aber auch nicht weniger.
Danke für dein Kommentar!
Wenn man aber ein solch komplexes FW nur für die Darbietung eines roten Fadens benutzt, ist der Einsatz schon Fehl am Platz, denke ich. Wenn man ein Framework nutzt, sollte man von vornherein wissen was man vorhat und in welche Richtung eine Seite gehen soll. Für Anfänger sind dann wirklich schlankere FWs besser geeignet, die ebenfalls eine Struktur einfordern.
Also dein Vergleich einer Form-Klasse mit einem HTML-schnipsel ist sehr schlecht gewählt, weil du da wirklich Birnen mit Äpfeln vergleichst, denn dein formular kann so in reinem html … garnichts!
– kein automatische wiederbefüllen mit werten
– keine fehlermeldungen ausgeben
Du hast also NUR das formular wie der user es beim ersten mal präsentiert bekommt (Create), nicht das formular wenn es mit werten vorgefüllt ist (Update) [sei es aus der DB, oder durch user-input nach einer fehlerhaften validierung] darstellen.
Dazu kommen die ganzen weiteren Features die Form-Klassen bieten:
– Filterung
– Validierung
– Decoratoren
– Übersetzungen von Labels, Values, ….
– Verarbeitung -> z.b. Uploads gleich passend irgendwo ablegen nach der filterung/validierung, …
Mit den richtigen Dekoratoren liese sich anstatt html z.b. auch xml [z.b. ein XUL-Interface für Mozilla-Browser], eine pdf, oder passende Objekte für ein GTK-Interface [es gibt ja php-gtk] generieren.
Alles das bedeutet Wiederverwendung von Code, ein wichtiges Ziel bei der Objekt-Orientierten Programmierung.
Client-seitige Validierung mit JS lässt sich mitgenerieren, man schreibt einmal einen passenden decorator der an die Validierung gebunden ist, der das passende JS dazu generiert und kann jederzeit die passende validierung auch im frontend sehen ohne das jedes mal händisch in seine html-forms einzufügen.
Noch dazu ist das Zend_Form-Beispiel schlecht gewählt, weil es eine Menge Decoratoren setzt die eigentlich nicht benötigt werden wenn man die Standard-Decoratoren nutzt [womit das Beispiel wohl nur noch halb so lang wäre], stattdessen wären es eher sinnvoll gewesen ein Code-Beispiel zu nehmen mit Filtern, Validatoren, etc und dann mal zu vergleichen wie viele zeichen code brauchst du um die funktionalität (wiederbefüllung, fehlermeldungen, filterung, validierung) nachzustellen ?
Einer der wichtigsten Lektionen die Form-Klassen, sei es von PEAR, Symfony, Zend oder anderen Frameworks bieten, lehren ist DRY – Don’t repeat yourself.
Man hat bei einer Formklasse eben auch eine wirkliche Verknüpfung zwischen der Abbildung des Formulars rein inhaltlich betrachtet und der generierung, wenn man den name eines Felds ändert, alle Feld-id/names prefixen will [z.b. weil man das Formular nochmal woanders nutzen will, aber dort schon ein feld mit der id "foo" existiert], sein default-value ändert oder felder hinzufügt, auch direkt eine Änderung des Outputs.
Wiederverwendbarkeit/Erweiterbarkeit ist gegeben [man kann von einer Form-Klasse ja auch erben und sie erweitern/spezialisieren].
Zur These “Ich gehe fest von der gewagten These aus, dass für versierte PHP-Coder die Entwicklung eines eigenen Frameworks genauso viel Zeit in Anspruch nimmt wie das Erlernen und Meistern vom Zend Framework.”
Meinst du damit nur routing und (h)mvc ? Da könnte würde ich sagen könntest du recht haben, aber wenn man die ganzen anderen Features die Frameworks wie Zend, Symfony, etc bieten mit in den Topf wirfst würde ich das bezweifeln.
Die Frage ist doch, was kommt dabei raus wenn ein einzelner Entwickler für sich zuhause allein sein Framework entwickelt ?
Ein auf seine aktuelle Applikation zugeschnittes Framework ? -> Sprich für die nächste schmeißt man es weg oder muss das alte umbauen ?
Ein Zusammenriss von allem was er irgendwann mehr als 2-3 mal gebraucht hat ?
Ich bin da der Meinung wenn mehrere Menschen Frameworks zusammen entwickeln kommen da oftmals besser wiederverwendbare und erweiterbare Systeme heraus wie man man selbst nur seine aktuellen und vergangenen Erfahrungen mit einfließen lässt, natürlich auch mehr Overhead.
Und wie schaut es aus wenn man mal nicht mehr alleine arbeitet ? Hat man sich Mühe gegeben den Code zu kommentieren (unter anderem PHPDoc), gibt es Tests, gibt es eine Doku, wen ausser dir kann man bei Problemen Fragen ? Eine Community die hilft ist oftmals auch ein relevanter Aspekt.
Allgemein zum Thema bekanntes Framework vs selbst gebasteltes Framework:
Ein zugeschnittes Framework das sich aus einer Applikation heraus entwickelt wird immer schneller sein als generische Web-Frameworks wie Zend, Symfony, CI, das ist klar, aber funktionales php wird auch schneller sein als OOP und C/C++/Assembler wird noch mal ein Stück schneller sein.
Frameworks sind immer ein Kompromis, sie sollen unter anderem dem Punkt entgegenwirken jedes mal das Rad neu zu erfinden, das kommt natürlich mit einem Preis, aber gerade wenn man sich anschaut was sich um Frameworks wie Zend, Symfony, CI, Kohana und co aussenherum entwickelt, Plugins, Erweiterungen, etc muss man auch sehen dass man unter Umständen einiges vorgefertiges für solche Frameworks findet was man ansonsten selbst planen, programmieren, dokumentieren muss, wo man bei Fragen/Problemen immer nur sich selbst hat.
Auch kommt es darauf an was am ende hinten rauskommt :)
Für viele kleine Projekte wird man sich nie wirklich Gedanken machen müssen was performance angeht, etc, nicht jeder programmiert täglich facebook, etc, oftmals sind es kleine projekte mit täglichen user-zahlen im 3-4 stelligen bereich die auf dem 08/15-webspace des kunden (sei es bei 1und1, strato, oder sonstwo) laufen.
Und für größere Projekte ergeben sich eh ganz andere Umfelde, oftmals programmiert man das aus Zeitgründen schon nicht alleine, die Chance andere begabte Programmierer zu finden die sich schon mit Symfony, CI, ZEnd, etc auskennen ist definitiv viel höher wie jemanden zu finden der dein persönliches vielleicht Applikations-bezogenes Framework kennt und wenn der erste Teil des Projekts nur daraus besteht seine(n/m) Mitprogrammier(ern) das eigene Framework zu erklären, geht das auch auf die Zeit und damit Kosten des Projekts und damit zu lasten des Kunden, der wenn man das von vorneherein plant und die zeit aufschlägt vielleicht jemand anders den zuschlag gibt.
Alles in allem ist die Frage, ob man ein Framework verwendet, selbst schreibt, verschiedene nutzt und soweiter auch von vielen weiteren Faktoren abhängig.
Macht man das ganze als Hobby ? Sprich spielt Zeit eine wirkliche Rolle, hat man Termindruck, …
Verdient man damit nur ein bißchen Geld dazu ?
Ist man selbstständig und muss damit seine kompletten brötchen verdienen ?
Arbeitet man in einer Firma mit vielleicht 2 oder mehr anderen Leuten zusammen ?
Wird das Projekt später vielleicht von anderen Leuten gepflegt ? …
mfg
Benjamin Steininger
Hallo,
vielen Dank für dein Kommentar. Mit einem eigenen Framework meine ich natürlich ein wiederverwendbares, das nicht nur auf eine Applikation zugeschnitten ist.
Du hast Recht, wenn du sagst eine objektorientierte Lösung diverser Websiteelemente würde für externe Komponente oder die spätere Auslagerung z.B. in XML Vorteile bringen. Aber mal ganz ehrlich: Für wieviele der “normalen” Webapplikationen trifft das zu? Ich habe ja nichts gegen die Komplexität, aber es ist einfach too much für die meisten Aufgaben.
> Für wieviele der “normalen”
> Webapplikationen trifft das zu?
Das kommt eben, wie Robo47 auch geschrieben hat, auf deine Situation an. Ich zB. arbeite in einem Umfeld, wo beides benötigt wird: Schnell umgesetzte Scripts ohne großes Budget wie auch große Applikationen, die die Standardisierung brauchen, die ein Framework bringt.
Das ist ja das schöne an PHP: Du kannst beide Wege gehen.
Ein Argument möchte ich nochmals betonen: Mit einem Framework bekommst du stabilen, getesteten Code mit einer ganzen Community dahinter, die Support bietet und eventuell auftauchende Fehler (und das müssen nicht nur Sicherheitslücken sein) in sehr kurzer Zeit behebt. Dieses Movement hast du mit selbstgeschriebenen, proprietären Code nicht.
@Robo47: Super geschrieben: Besser kann man es imho nicht ausdrücken.
Zend Framework News » Blog Archive » Warum man das Zend Framework nicht immer einsetzen sollte
Wie der robo47 bereits angemerkt hat hinkt dein Vergleich gewaltig.
Womit du aber definitiv recht hast:
Zend Framework – und jedes andere Framework – hat seine Existenzberechtigung nicht für kleine 0815 Projekte, wobei selbst diese oft riesengroße CMS mit riesengroßer Library verwenden, die sehr unnötig ist.
Für den typischen php Anfänger ist es mit Sicherheit auch ungeeignet, da die Lernkurve sehr intensiv ist.
Interessant werden ZF, Symphony und auch codeIgniter vorallem dann, wenn man viel mit unterschiedlichen Programmierern zusammenarbeitet, oder zu erwarten ist, dass regelmäßig neue Personen mit dem Quellcode in Berührung kommen (OpenSource).
Denn dann sind die Community Ressources wahnsinnig hoch und vorallem die Chance, dass der Neue/die Neue bereits mit ähnlichen Projekten zu tun hatte.
Sollte man also jemals einen Freelancer bei seinen Projekten haben, wird er sehr dankbar sein, wenn das Framework bekannt ist.
Für jeden PHP Programmierer empfiehlt sich meiner Ansicht nach PHP ordentlich zu lernen (quick & dirty, meine eigene Funktionssammlung, OOP, mein eigens Framework) und dann erst mit einem der großen Frameworks anzufangen.
Ansonsten muss man Zwangsweise daran scheitern, das Werkzeug nicht zu kennen das man verwendet.
just my 2 cents
Du hast Recht, der Einsatz eines Frameworks ist bei wechselnen Programmieren extrem Vorteilhaft. Bei einem würde ich dir aber widersprechen:
Ich denke, bevor man ein eigenes Framework entwickelt, sollte man erst ein oder zwei probiert haben, damit man bei seinem eigenen FW die Dinge besser macht die einem beim “offiziellen” Framework gestört haben.
Ich empfehl dazu diesen tollen post dem ich sehr zustimme, daher auch diese Aussage :)
Btw: sehr sehr cooles Blog Design : )
Ich finde diesen Blogbeitrag einfach nur Schwachsinn. Hast du schonmal daran gedacht, das eine Formularklasse ein wenig mehr macht als dein HTML Code?
Es fragt auch noch gleich ein paar Sachen ab? Und ja, du arbeitest 100 mal schneller mit einem Framework als mit reinem PHP.
Ich habe mich ca. 5 Stunden in das APF Framework reingearbeitet. Nun kann ich ziemlich viel für die 5 Stunden.
1. Formulare ausgeben, validieren und bei Fehler darauf reagieren!
2. Mit MySQL Datenbanken arbeiten
3…….
Dies in 5 Stunden mal auf die Schnelle zu lernen ist eig. mit PHP schlecht zu realisieren..
Habe nun in 5 Stunden eine Registrierung, Login, Impressum, Kontakt programmiert. Und das Ohne BUGS, Angriffbaren stellen. Klar können Fehler im Framework sein, aber weniger als wenn ich es von Hand alles programmiert hätte!
Fazit: Ein hoch auf PHP Frameworks! Vorallem auf das APF!!
Ich sage ja nicht, dass PHP Frameworks etwas schlechtes sind. Und auch wenn der Nutzen eines Frameworks unbestreitbar ist und APF durchaus seine Daseinsberechtigung hat: Kann es nicht sein, dass man eine solche Applikation mit einem kleineren Framework (kleinerer Footprint, weniger Overhead, mehr Performance, weniger Einarbeitungszeit) in der gleichen Zeit geschafft hätte? Und: in fünf Stunden eine Registrierung, einen Login und eine Kontaktseite zu erstellen sollte auch ohne Framework möglich sein.
@Jens P
bleib mal ganz geschmeidig, due hast ne Registrierung, ein Login und einen Kontakt und Impressum in 5 Stunden Programmiert? Ok und wieviel hast du wirklich verstanden was beim APF vor sich geht? Wie groß war dein Lerneffeckt wirklich zu begreifen was da vor sich geht? Das was du da in 5 Stunden gemacht hast mit einem riesen Framework (was zu 100%) seine Daseinberechtigung hat, mache ich dir mit eigenem Code auch in 5 Stunden oder weniger und vor allem da ich es selber schreibe weis ich aber was da warum wie passiert, ich wette das dies bei dir nicht der Fall ist. Und nein ich verwende kein MVC weil ich es aber auch nocht nicht so wirklich verstehe, also warum soll ich zum Beispiel so ein Framework benutzen wenn ich das MVC selber so noch nicht kapiere.
Wie gesagt Frameworks ob PHP, Js, .NET oder was auch immer haben ihr Daseinsberechtigung, aber es gibt viele kleine Projekte (nicht 0815) wo man es einfach nicht benötigt.
Wobei ich mich nun aber mal ins Symfony einarbeiten werde sonst peile ich das MVC wohl nie.
Den Vergleich mit dem HTML Formular und einer Form Klasse finde ich allerdings auch ein wenig schräg, weil das kein Vergleich ist der wirklich etwas repräsentiert um sagen zu können man bracuht für 0815 Projekte (was für ein blöder Ausdruck das ist) kein Framework einzusetzen. Ich denke du solltest das vieleicht auf einen anderen Bezugspunkt ausweichen um einen wirklich sinnvollen Vergleich, oder besser gesagt eine bessere Begründung geben zu können.
Mfg Litter
7 Dinge, die professionellen Webdesignern nicht passieren dürfen « SHIFT Website Development Weblog
XSS: Der richtige Schutz vor Cross-Site-Scripting mit PHP « SHIFT Website Development Weblog
This is not sexy: PHP-Template-Engines á la Smarty « SHIFT Website Development Weblog
Ich selbst nutze auch Codeigniter als PHP-Framework und bin für fast alle meine Projekte damit bestens ausgestattet.
Von der Geschwinigkeit und der Ausstattung her bin ich sehr Positiv angetan und die ordentliche Dokumentation lässt schnell finden, was man sucht.
Sicher könnte man auch ohne Frameworks abreiten, aber für schnelles Arbeiten sind diese eine riesen erleichterung. Um ein Formular zu überprüfen genügt meist nur ein Absatz.
Fazit:
Berufliche Programmierer kommen nicht drum herum, Hobbyprogrammierer dürften den Aufwand zur Erlernung von Architekturmustern und Eigenheiten eines Frameworks eher scheuen.
Hallo Namensvetter!
CodeIgniter ist in meinen Augen ein schlankes, einfaches Framework, welches nur einen Bruchteil des Overheads eines Zend Frameworks mit sich bringt.
einige kritische kommentare haben den artikel nicht gelesen. wer eine volle funktionalitaet eines formulares braucht fuer den stellt sich die frage framework ja/nein gar nicht.
es sollte ein durchaus provokanter vergleich sein fuer den der etwas einfaches bauen moechte: sei es der einfache tisch im uebertragenen sinn oder ein einfaches formular welches eben nur ein einfaches formular sein soll.
das beispiel passt, der artikel ist gut.
einige kommentar sind dagegen typisches pawlowsches beissen.