KAPITEL 1
Warum Laravel?
In den frĂŒhen Tagen des dynamischen World Wide Web sah das Schreiben einer Anwendung ganz anders aus als heute. Die Entwickler waren damals nicht nur dafĂŒr verantwortlich, den Code fĂŒr die jeweils spezielle Anwendungslogik zu schreiben, sondern auch fĂŒr all jene Komponenten, die immer wieder fĂŒr Websites benötigt werden: fĂŒr die Authentifizierung von Benutzern, die Validierung von Eingaben, Datenbankzugriffe, die Erstellung von Vorlagen und vieles mehr.
Heutzutage gibt es Dutzende von Frameworks fĂŒr die Anwendungsentwicklung und Tausende von Komponenten und Bibliotheken, die allen Programmierern leicht zugĂ€nglich sind. Es ist gĂ€ngige Rede unter Entwicklern, dass, kaum habe man ein Framework gelernt, es bereits drei neuere (und angeblich bessere) Frameworks gebe, die es gerne ersetzen möchten.
»Weil er halt existiert«, mag eine sinnvolle Rechtfertigung dafĂŒr sein, einen Berg zu besteigen. Aber es gibt bessere GrĂŒnde als »Weil es halt existiert«, um sich fĂŒr ein bestimmtes Framework zu entscheiden â oder ĂŒberhaupt eines zu verwenden. Stellen wir uns also die berechtigte Frage: Wozu sind Frameworks eigentlich gut? Genauer gesagt: Wozu ist Laravel gut?
Warum ein Framework verwenden?
Es ist leicht nachzuvollziehen, warum es hilfreich ist, die einzelnen Komponenten und Pakete zu verwenden, die es fĂŒr PHP-Entwickler gibt. Bei Packages ist jemand anderes fĂŒr die Entwicklung und Wartung eines isolierten StĂŒcks Programmcode verantwortlich, mit dem eine bestimmte Aufgabe gelöst wird, und theoretisch sollte diese Person ein tieferes VerstĂ€ndnis fĂŒr diese einzelne Komponente besitzen, als Sie sich selbst in angemessener Zeit aneignen können.
Frameworks wie Laravel â und Symfony, Lumen und Slim â versammeln eine Reihe Komponenten von Drittanbietern und bĂŒndeln diese mit Framework-eigenem »Klebstoff« wie Konfigurationsdateien, Service Providern, vordefinierten Verzeichnisstrukturen und Anwendungs-Bootstraps. Ganz allgemein besteht der Vorteil, ein Framework zu verwenden, darin, dass jemand fĂŒr Sie nicht nur bereits ĂŒber einzelne Komponenten entschieden hat, sondern auch darĂŒber, wie diese Komponenten zusammenarbeiten sollen.
»Ich baue es einfach selbst«
Nehmen wir an, Sie beginnen mit einer neuen Webapplikation, ohne die Vorteile eines Frameworks zu nutzen. Womit fangen Sie an? Ziemlich sicher mĂŒssen HTTP-Requests geroutet werden, sodass Sie sich alle verfĂŒgbaren HTTP-Request- und Response-Bibliotheken anschauen und danach eine auswĂ€hlen mĂŒssen. Dann brauchen Sie einen Router. Und wahrscheinlich benötigen Sie auch irgendeine Art Konfigurationsdatei fĂŒr die Routen. Welche Syntax soll dabei verwendet werden? An welcher Stelle soll die Konfigurationsdatei abgelegt werden? Und was ist mit Controllern? Wo sollen die liegen und wie sollen sie geladen werden? Wahrscheinlich benötigen Sie einen Dependency Injection Container, um die Controller und ihre AbhĂ€ngigkeiten aufzulösen. Aber welchen?
Wenn Sie sich die Zeit nehmen, all diese Fragen zu beantworten und Ihre Anwendung erfolgreich zu erstellen, was bedeutet das dann fĂŒr einen möglichen spĂ€teren Entwickler? Und was machen Sie, wenn Sie beispielsweise vier dieser Anwendungen mit solch einem Framework Marke Eigenbau programmiert haben â oder gar ein ganzes Dutzend â und Sie sich jeweils daran erinnern mĂŒssen, wo sich die Controller befinden oder wie genau die Routing-Syntax lautet?
Konsistenz und FlexibilitÀt
Frameworks lösen dieses Problem, indem sie eine sorgfĂ€ltig durchdachte Antwort auf die Frage »Welche Komponente sollen wir verwenden?« geben und zudem sicherstellen, dass die jeweils gewĂ€hlten Komponenten auch gut zusammenarbeiten. DarĂŒber hinaus bieten Frameworks feste Konventionen, die die Menge an Code reduzieren, die ein Entwickler, der neu zu einem Projekt stöĂt, verstehen muss: Sobald Sie begriffen haben, wie Routing in einem Laravel-Projekt funktioniert, wissen Sie sofort, wie es in allen Laravel-Projekten funktioniert.
Wenn jemand vorschreibt, dass sein eigenes Framework fĂŒr jedes neue Projekt benutzt werden muss, dann geht es letztlich darum, zu kontrollieren, was in die Grundlage seiner Applikation einflieĂt und was nicht. Das bedeutet, dass Ihnen die besten Frameworks nicht nur ein solides Fundament bieten, sondern auch die Freiheit geben, praktisch alles Ihren eigenen WĂŒnschen entsprechend anzupassen. Und genau das ist es, was Laravel so besonders macht und was ich Ihnen im weiteren Verlauf dieses Buchs zeigen möchte.
Eine kurze Geschichte der Web- und PHP-Frameworks
Will man die Frage »Warum Laravel?« beantworten, muss man seine Geschichte kennen â und seine VorlĂ€ufer. Bevor Laravel populĂ€r wurde, gab es bereits eine Vielzahl von Frameworks und anderer Entwicklungen in PHP und verwandten Bereichen.
Ruby on Rails
David Heinemeier Hansson veröffentlichte 2004 die erste Version von Ruby on Rails, und seitdem ist fast jedes Web Application Framework in irgendeiner Weise von Rails beeinflusst.
Rails popularisierte MVC, das Model-View-Controler-Paradigma, aber auch RESTful JSON APIs, die Regel »Konvention vor Konfiguration«, ActiveRecord und viele weitere Tools und Konventionen, die einen groĂen Einfluss auf die Art und Weise hatten, wie Webentwickler an ihre Anwendungen herangingen â insbesondere im Hinblick auf die schnelle Anwendungsentwicklung.
Eine Welle von PHP-Frameworks
Es war den meisten Entwicklern klar, dass Rails und Ă€hnliche Frameworks die Zukunft darstellten, und schnell erschienen PHP-Frameworks auf der BildflĂ€che, einschlieĂlich derjenigen, die zugegebenermaĂen Rails imitierten.
CakePHP war im Jahr 2005 das erste, und es folgten bald Symfony, CodeIgniter, Zend Framework und Kohana (ein CodeIgniter-Fork). 2008 kam Yii, und 2010 erschienen Aura und Slim. 2011 sah dann die Geburt von FuelPHP und Laravel, die beide als CodeIgniter-Alternativen vorgeschlagen wurden.
Einige dieser Frameworks orientierten sich eher an Rails und konzentrierten sich auf objektrelationale Abbildung (Object-relational mapper, ORM), MVC-Strukturen und andere Tools fĂŒr eine rapide Entwicklung. Andere â wie Symfony und Zend â konzentrierten sich mehr auf Enterprise Design Patterns und E-Commerce.
Das Gute und das Schlechte an CodeIgniter
CakePHP und CodeIgniter waren die beiden frĂŒhen PHP-Frameworks, bei denen klar kommuniziert wurde, wie sehr sie von Ruby on Rails inspiriert waren. CodeIgniter wurde schnell bekannt und war 2010 wohl das beliebteste der unabhĂ€ngigen PHP-Frameworks.
CodeIgniter war simpel, einfach zu bedienen, besaĂ eine erstaunlich gute Dokumentation und wurde von einer starken Community gestĂŒtzt. Aber der Einsatz moderner Technologien und Entwurfsmuster schritt nur langsam voran. Als die Framework-Welt wuchs und die PHP-Tools weiterentwickelt wurden, begann CodeIgniter sowohl in Bezug auf den technologischen Fortschritt als auch auf die Funktionen, die es out of the box mitbrachte, ins Hintertreffen zu geraten. Im Gegensatz zu vielen anderen Frameworks wurde CodeIgniter von einem Unternehmen verwaltet, und es dauerte einige Zeit, bis man die neueren Features von PHP 5.3 wie Namespaces, die Nutzung von GitHub und spĂ€ter Composer aufgriff. Im Jahr 2010 war Taylor Otwell, Laravels Schöpfer, schlieĂlich so unzufrieden mit CodeIgniter, dass er begann, sein eigenes Framework zu schreiben.
Laravel 1, 2 und 3
Die erste Beta von Laravel 1 wurde im Juni 2011 veröffentlicht und war eine komplette Neuentwicklung. Sie beinhaltete einen eigenen objektrelationalen Mapper namens Eloquent, ein Closure-basiertes Routing (inspiriert von Ruby Sinatra), ein modulares Erweiterungssystem und Hilfsfunktionen fĂŒr Formulare, Validierung, Authentifizierung und vieles mehr.
Die frĂŒhe Entwicklung von Laravel ging schnell voran, und Laravel 2 und 3 wurden bereits im November 2011 bzw. Februar 2012 veröffentlicht. In diesen Versionen wurden Controller, Modul-Tests, ein Befehlszeilen-Tool, ein Container mit Inversion of Control (Steuerungsumkehr), Relationen zwischen Eloquent-Modellen sowie Migrationen eingefĂŒhrt.
Laravel 4
FĂŒr Laravel 4 hat Taylor Otwell das gesamte Framework noch einmal von Grund auf neu geschrieben. Zu diesem Zeitpunkt war Composer, der inzwischen allgegenwĂ€rtige Paketmanager von PHP, bereits auf dem Weg dazu, sich zu einem Industriestandard zu entwickeln, und Taylor sah einen groĂen Mehrwert darin, das Framework als eine Sammlung von Komponenten zu konzipieren, die von Composer verteilt und zu einem Ganzen gebĂŒndelt wurden.
Er entwickelte eine Reihe von Komponenten unter dem Codenamen Illuminate und brachte im Mai 2013 Laravel 4 heraus, das eine völlig neue Struktur besaĂ. Anstatt das Framework als einen groĂen Download anzubieten, zieht sich Lara...