Wahl Framework

[ChristianK]

Weil es diverse Kritiken an ORM's gibt. Also die eine "Glaubenshälfte" bevorzugt ORM's und die andere DSL. Das ist denke ich mehr ein Glaubenskrieg, als etwas wirklich technisch begründetes. Mit anderen Worten, es ist reine Geschmackssache, ob ORM oder DSL.
[...]

Irch selber bin ein guter Verfechter von ORM. Ich finde es ist echt nicht notwendig, eine weiter Sprache zu implementieren, die genau das macht, wofür SQL vorgesehen ist. Das ist, als ob du alle PHP-Skripte in XML definieren würdest. SQL ist so mächtig und vieles, was man mit ORM nicht so einfach machen kann (oder mit DQL nur kompliziert), kann in SQL einfach gelöst werden. Wenn, dann einen QueryBuilder einsetzen, um dynamisch SQL zu generieren. ORM ist oftmals im ersten Schritt sehr schnell: man hat schnell Entities, daraus sogar ohne eine zeile SQL die DDL generiert und eine DB migriert. Sobald die Software allerdings komplexer wird, stösst man mit ORM an die Grenzen und wäre froh, hätte man von Anfang an auf rines SQL gesetzt und Row Mapping gesetzt.

Angenommen ihr würdet ein kleines Shoppingsystem für eure Firma zusammenbasteln, würdet ihr das von Hand coden (so würde ich es nach meinem aktuellen Kenntnisstand lösen) oder würdet ihr als unterstützende Maßnahme ein Framework nehmen? Als Vorteil per Hand sehe ich ganz klar, dass es schneller geht, aufgrund der nicht vorhandenen Einarbeitungszeit in ein Framework. Andererseits denke ich, die Einarbeitung in ein Framework kostet zwar Zeit, ist aber sicherer im Bezug auf Angriffe.

Ein "Framework" brauchst du so oder so. Es ist sinnlos, die Basis wie z.B. Firewall, HTTP-Request-Handling, Session-Handling stets neu zu programmieren. Wenn du z.B. Symfony nimmst kannst du (wenn du Doctrine löschst) mit der Basisinstallation nur genau das. Du kannst Routen definieren und Controller, die entsprechend Aktionen ausführen. Darauf kannst du ein x-beliebiges System bauen.

[JaMa]

Ich verstehe nicht, warum eine komplett selbstgeschriebene Implementierung schneller sein soll, also die Einarbeitung in ein Framework. Klar wenn das fertige System nur ein sehr simples CMS oder Blog System sein soll, das ein paar Datensätze in die Datenbank schreibt und daraus liest kann man das vllt. noch annhemen. Aber alles was darüber hinausgeht ist mit Framework einfach schneller, trotz Einarbeitungszeit. Bei einer kompletten Selbstimplementierung verbringst du im Laufe der Entwicklung so viel Zeit für die Entwicklung von Libraries oder Tools (was schon massig vorhanden ist), in der du die eigentliche Anwendungslogik programmieren könntest.
Und die Einarbeitungszeit hast du als einmalige Investition (wobei man ja bei der Entwicklung auch noch ständig lernt), was dir dann bei vielen weiteren Projekten noch zu Gute kommen wird.

Von vielen Kunden wirst du eine komplette Plain-PHP Entwicklung ohne Framework meist sowieso nicht genehmigt bekommen, da die Kunden für die Entwicklung der Anwendungslogik bezahlen wollen und nicht für die Entwicklung von etwas, was schon etliche Male vorhanden ist.

- Nur meine 2 Pfennig -

[derwunner]

Wie auch immer, zurück zum Thema. Also, wir halten fest, Frameworks sind sinnvoll und sie sind auch die Einarbeitungszeit wert. Heißt jetzt im Endeffekt für den Thread Autor, dass er oder sie sich frei entscheiden kann bei der Wahl seines Frameworks. Alle Kriterien und alle anderen Punkte, die er oder sie bei der Wahl beachten sollte, wurden genannt. Meine Empfehlung ist ganz klar Symfony. Denn Symfony ist modular aufgebaut und man kann einfach Komponenten raus schmeißen, die man nicht braucht. Genauso gut kann man auch Symfony um weitere Komponenten erweitern. Die Community bietet hierfür eine riesige und fantastische Auswahl an vorgefertigten Bundles/Komponenten. Spontan fällt mir da z. B. das FOSRoutingBundle ein.

Ach und außerdem, um es mit den Symfony Worten zu sagen: "The wunderfull world of composer". Mit anderen Worten, man muss kein fertiges Framework nehmen, man kann sich auch voneinander unabhängige Komponenten zusammen holen. Das geht mit Composer ganz leicht. Spontan einfallen würden mir da eine Dependency Injection Lib, eine From Componenent, einen Auth Handler und ein Basis Controller/Action Handler.

[webdevv]

Also Symfony gefällt mir von der Handhabung echt gut und ein großes Plus sind die Videotutorials, die auf der Seite angeboten werden.

http://knpuniversity.com/screencast/...ello-twig#play

[derwunner]

Also Symfony gefällt mir von der Handhabung echt gut und ein großes Plus sind die Videotutorials, die auf der Seite angeboten werden.

http://knpuniversity.com/screencast/...ello-twig#play

Ja, von KNP University habe ich auch die Bezahlvideos gesehen. Absolut empfehlenswert! Die vermitteln verständlich die ganzen Symfony Techniken, und was alles dazu gehört. Also auch Doctrine und sowas. Echt gut die Seite, kann ich nur wärmstens empfehlen. Und ein paar schlappe Euro im Monat sollte sich jeder leisten können. Die Videos sind es definitiv wert. Man kann auch alle Kurse herunterladen, samt Manuskript und Code. Also das ganze einen Monat zu bezahlen reicht theoretisch aus. Man kann sich ja wie gesagt alles herunterladen.

[lottikarotti]

Zwischen den beiden Extremen "alles selber coden" und "ganzheitliches Framework nutzen" gibt es auch die Variante mit einzelnen Komponenten zu arbeiten. Einfach Composer installieren, die notwendigen Komponenten zusammenwürfeln (siehe https://packagist.org/) und loslegen.

[webdevv]

Hallo,


ich muss meine Aussage revidieren. Ich nutze nun Laravel und bin bis jetzt sehr zufrieden damit. Es ist einfacher als ich anfangs dachte, dennoch sehr umfangreich. Ich schätze bis ich alles kennen gelernt habe, dauert es noch ein paar Wochen.
So das Grundlegende beherrsche ich bereits und es macht unheimlich Spaß. Weiterhin kann ich auch hier die Videotutorials auf laracasts.com empfehlen, für 9€ ein Schnäppchen.

Grüße
webdevv

[Gast]

Für ein neues Projekt in meinem Job haben wir uns auf das Experiment Laravel eingelassen (Nach jahrelangem Verwenden von Symfony2/3) und wir sind begeistert. Da es auf Symfony-Komponenten aufbaut, die ja mittlerweile beinahe einen Quasi-Standard darstellen, kommt man sehr schnell hinein.

Und dann merkt man, dass für fast alle Business-Cases bereits Lösungen existieren. Bisher sind wir auf keine Anforderung gestoßen, für die nicht bereits eine komplette Implementierung oder zumindest unterstützende Strukturen gibt.

Auch, wenn ich Active record aufgrund des fehlenden Unit of work nicht so mag, ist Eloquent als ORM sehr einfach und vor allem praktisch zu benutzen. Mittlerweile sind wir an dem Punkt angelangt, dass wir es auch für andere Projekte nutzen werden.

Der große Vorteil, den ich gegenüber Symfony sehe, ist, dass alle Mechanismen von dort übernommen wurden, aber wesentlich unomplizierter zu benutzen sind.

Das Einzige, dass zu beachten ist, ist, dass man sich selbst bei der Nutzung disziplinieren muss. Auch, wenn es überall propagiert wird, halte ich das Benutzen der sogenannten "Facades" für problematisch und sollte doch lieber den sehr mächtigen DI-Container verwenden.

[monolith]

@webdevv Du musst nicht alles beherrschen lernen. Ich arbeite seit mehreren Jahren mit Laravel und vieles was zuletzt so kam habe ich mir noch nicht genauer angeschaut. Das ist aber ja kein Problem, Laravel ist extrem gewachsen und vieles benötigt man halt nur in bestimmten Fällen. So lange die nicht eintreten, muss man sich auch nicht zwangsweise damit beschäftigen. Okay, einmal die Doku dazu durchlesen kann nicht schaden damit man weiß worum es grundsätzlich geht. (Wobei mir dazu leider zuletzt die Zeit fehlte da ich derzeit fast nur mit Symfony arbeite ...)

xm22 Ich höre immer wieder, Laravel baue auf Symfony-Komponenten auf. Das ist zwar nicht falsch, aber die Aussagekraft ist meiner Meinung nach eigentlich nur minimal. Es hat früher etwas mehr verwendet aber jetzt nutzt es soweit ich weiß von Symfony noch das Routing und die HTTP Foundation Komponente und... das war's schon, jedenfalls im Wesentlichen. Das sind letztlich auch nur Komponenten unter vielen weiteren Komponenten, die via Composer eingebunden werden. Oder ich verstehe dich falsch und du meinst das anders.

Facades sind bei Laravel eigentlich schon seit öh ich glaube 5.0 out. Ja es gibt sie noch, aber inzwischen wird eigentlich mehr konventionellere DI via Konstruktor/Methoden in den Vordergrund gestellt.