Es gibt so manche, die nach wie vor noch keine Erfahrungen mit Frameworks gesammelt haben, da es nach wie vor noch Unternehmen gibt, die in Eigenregie ihre Software von Grund auf neu bauen. Ebenfalls gibt es einige Interessenten die sich überlegen, auf ein Framework zu wechseln, hierbei stellt sich die Frage „Welches Framework wollen wir nutzen?“. In diesem Artikel geht es darum abzuwägen ob das Framework „Laravel“ für den Business-Need in Frage kommen kann.
Laravel basiert auf einigen Dingen wie z.B. den Commands für CLI auf Symfony. Symfony ist, wie man es in Entwicklerkreisen kennt, wahrhaftig ein gutes Framework. Ebenso implementiert es einige third-party libraries über composer, von denen man in erster Linie noch nie was zuvor gehört hat.
In erster Linie um diese Frage zu beantworten: Laravel eignet sich meiner Erfahrung nach mit dem „Framework“ nur für kleine Applikationen bzw. Projekte. Mit Sicherheit kann man damit auch komplexere Anwendungen bauen, jedoch sollte man sich auch die Frage stellen: „Welchen Aufwand möchte ich betreiben um eine Applikation zu entwickeln?“ Wird der Business-need groß, so eignet sich Laravel vermutlich eher weniger um diesen vollständig abzudecken, da in vielerlei Richtungen man nicht drum herum kommt Vanilla-PHP zu schreiben, da das „Framework“ eher einen sehr geringen Business-Case an üblichen Anforderungen an Enterprise-Anwendungen abdeckt. Damit steigen die Aufwände zum Implementieren von Features. Einerseits kann das sehr wohl auch ein guter Business-Case sein, denn letztlich hat man damit vermutlich auch viel in der eigenen Hand und kann damit viel aus eigener Hand abdecken. Andererseits steigert es den Grad an Fehleranfälligkeit, da Dinge neu entwickelt werden müssen, die jedes Enterprise-Framework wie z.B. Symfony oder das Zend Framework (aka nun neuerdings Laminas) von Haus aus abdecken und vor allem getestet sind.
An sich ist Laravel dennoch nicht schlecht. Es implementiert bekannte Libraries wie PHP/DI um z.B. Dependency-Injection damit abzubilden, damit zumindest für altbewährte Entwickler ein nützlicher Grad an Wieder, Austausch- und Ersetzbarkeit.
Jedoch bzgl. der Best-Practises im Jahr 2020 hinkt Laravel stark hinterher. Laravel Best-Practises decken sich nicht mit den OOP-Standards, hierbei als Beispiel aufgeführt die Eloquent-Models in Laravel, welche einen einzelnen Datensatz in der Datenbank als Objekt im Eloquent-ORM zur Verfügung stellen und damit auf jedes der Spalten-Namen als public attribute zugegriffen werden kann.
Die objektorientieren Leitsätze/Best practises werden hierbei aufgebrochen. Klar es bietet auch die Möglichkeit Mutators und Accessors zu setzen, welche dynamisch dafür sorgen dass die Manipulation der Attribute innerhalb von Methoden-Scopes nach wie vor möglich ist, beim Laden und Speichern der Models, jedoch ist dies sehr begrenzt im Vergleich dazu, wenn man sich an die OOP-Standards halten würde.
Zudem kommt hinzu, dass Laravel sehr großen Wert auf callStatic, call, get, set legt als magische Methoden legt, womit ohne weitere PHPStorm-Plugins viel an Sourcecode nicht nativ interpretierbar ist bzw. wofür es keine code complemention gibt.
Ein weiterer Faktor ist das Thema Typisierung, wir als Entwickler kennen es (zumindest die, die die Changelogs lesen und damit wissen wohin die Reise geht), dass PHP immer mehr und mehr Wert auf Typisierung legt. PHP 7 führt schon Ansatzweise eine sehr fortschrittliche Typisierung ein und legt damit einen Baustein zum Typisieren in der PHP-Szene ab.
Laravel kümmert dies alles herzlich wenig. Sowohl die Dokumentation als auch die Implementation setzt vorraus, dass auch mit typ unspezifischen Implementationen umgegangen werden kann. Das ist insgesamt sehr hinderlich, wenn man als Entwickler code pflegen muss, allerdings nicht weiß in welcher Form man es a) performant gestalten kann b) um was es sich in der entsprechenden Codestelle handelt, das wissen hier geht verloren, sodass nur der jenige der es initial gebaut hat, die Frage beantworten kann oder noch schlimmer:
mehrere Typen sind möglich und damit muss von case zu case anders mit den eingehenden Daten umgegangen werden -> keine einheitliche Basis.
Dies wird in großen Teilen gerade bzgl. der Models von Laravel präferiert. Ebenso in weiten Teilen ist Laravel auch nicht RFC konform, mittlerweile hat sich das durchaus gebessert. Allerdings nicht in dem Rahmen wie es wünschenswert wäre.
Symfony oder Zend Framework Aka Laminas haben den Vorteil, dass vieles an Bestandskomponenten die im Prinzip jede Enterprise Applikation braucht (hierbei bezeichne ich „Enterprise“ als alles was einen Business-need“ mit sich bringt) von Haus aus mitbringt. Keine lästige Entwicklung von Bestandskomponenten und das wichtigste: RFC konform!
Wer mag schon blacklisted werden beim Mailversand oder anderes.
Zudem kommt hinzu, dass bei jedem der Laravel Upgrades man aufpassen muss, dass man sich keine third party packages (ja gibt es auch unter symfony oder laminas) zerschießt, meistens in den versionsunterschieden gibt es erhebliche breaking changes auch bei minor updates oder patches (anders als bei symfony oder laminas die semver leben).