Pourquoi devrais-je utiliser Laravel Framework

Dans les premiers jours du Web dynamique, l'écriture d'une application Web était très différente de ce qu'elle le fait aujourd'hui. Les développeurs étaient alors responsables de la rédaction du code non seulement de la logique métier unique de nos applications, mais aussi de chacun des composants si courants sur les sites - authentification des utilisateurs, validation des entrées, accès à la base de données, modèles et plus encore.

Aujourd'hui, les programmeurs ont des dizaines de cadres de développement d'applications et des milliers de composants et de bibliothèques facilement accessibles. C'est un refrain courant parmi les programmeurs qui, au moment où vous apprenez un cadre, trois frameworks plus récents (et prétendument mieux) ont surgi dans l'intention de le remplacer.

«Juste parce qu'il est là» pourrait être une justification valable pour gravir une montagne, mais il y a de meilleures raisons de choisir d'utiliser un cadre spécifique - ou d'utiliser un cadre du tout. Cela vaut la peine de poser la question: pourquoi les cadres? Plus précisément, pourquoi Laravel?

Pourquoi utiliser un cadre?

Il est facile de voir pourquoi il est avantageux d'utiliser les composants ou packages individuels qui sont disponibles pour les développeurs PHP. Avec des forfaits, quelqu'un d'autre est responsable du développement et du maintien d'un morceau de code isolé qui a un travail bien défini, et en théorie cette personne a une compréhension plus profonde de ce composant unique que vous avez le temps d'avoir.

Des frameworks comme Laravel - et Symfony, Silex, Lumen et Slim-Prepackage une collection de composants tiers ainsi que des fichiers de configuration de Framework personnalisés, des fournisseurs de services, des structures de répertoire prescrites et de l'amraison. Ainsi, l'avantage d'utiliser un cadre en général est que quelqu'un a pris des décisions non seulement sur les composants individuels pour vous, mais aussi sur Comment ces composants devraient s'adapter.

"Je vais juste le construire moi-même"

Disons que vous démarrez une nouvelle application Web sans l'avantage d'un cadre. Où commencez-vous? Eh bien, il devrait probablement acheminer les demandes HTTP, vous devez donc maintenant évaluer toutes les bibliothèques de demande et de réponse HTTP disponibles et en choisir une.

Puis un routeur. Oh, et vous aurez probablement besoin de configurer une forme de Fichier de configuration des routes. Quoi syntaxe si elle utilise? Où devrait-il aller? Qu'en est-il de contrôleurs? Où vivent-ils et comment sont-ils chargés?

Eh bien, vous probablement Besoin d'une injection de dépendance conteneur pour résoudre les contrôleurs et leurs dépendances, mais qui?

De plus, que se passe-t-il si vous prenez le temps de répondre à toutes ces questions et de créer avec succès votre application - quel est l'impact sur le prochain développeur?

Qu'en est-il lorsque vous avez quatre de ces applications basées sur le framework, ou une douzaine, et vous devez vous rappeler où les contrôleurs vivent dans chacun, ou quelle est la syntaxe de routage?

Les cadres de cohérence et de flexibilité abordent ce problème en fournissant une réponse soigneusement réfléchie à la question «quel composant devons-nous utiliser ici?"Et s'assurer que les composants particuliers choisis fonctionnent bien ensemble. De plus, les cadres fournissent des conventions qui réduisent la quantité de code qu'un développeur nouveau dans le projet doit comprendre - si vous comprenez comment le routage fonctionne dans un projet Laravel, par exemple, vous comprenez comment il fonctionne dans tous les projets Laravel.

Lorsque quelqu'un prescrit en lancement de votre propre cadre pour chaque nouveau projet, ce qu'il préconise est la possibilité de contrôler ce qui fait et ne fait pas dans les bases de votre application.

Cela signifie que les meilleurs frameworks vous fourniront non seulement une base solide, mais vous donnera également la liberté de personnaliser au contenu de votre cœur.

Une courte histoire des cadres Web et PHP

Une partie importante de pouvoir répondre à la question «pourquoi Laravel?«Comprend l'histoire de Laravel - et comprendre ce qui avant. Avant l'augmentation de la popularité de Laravel, il y avait une variété de cadres et d'autres mouvements dans PHP et d'autres espaces de développement Web.

Ruby sur les rails

David Heinemeier Hansson a publié la première version de Ruby on Rails en 2004, et il a été difficile de trouver un cadre d'application Web depuis lors qui n'a pas été influencé par les rails d'une manière ou d'une autre.

Les rails ont popularisé MVC, les API JSON RESTful, la convention sur la configuration, le record actif et bien d'autres outils et conventions qui ont eu une profonde influence sur la façon dont les développeurs Web ont approché leurs applications - en particulier en ce qui concerne le développement rapide des applications.

L'afflux de cadres PHP

Il était clair pour la plupart des développeurs que les rails et les cadres d'applications Web similaires étaient la vague du futur, et les cadres PHP, y compris ceux qui imitent certes des rails, commençant à apparaître rapidement.

Gâteau était le premier en 2005, et il a été rapidement suivi de Symfony, Codeigniter, Zend Framework et Kohana (une fourche Codeigniter).

Yii Arrivé en 2008, Aura et Slim en 2010. 2011 a amené FuelPhp et Laravel, qui n'étaient pas tout à fait des ramifications de Codeigniter, mais ont plutôt proposé comme alternatives. Certains de ces cadres étaient plus des rails, se concentrant sur les mappeurs de la base de données et les mappeurs (ORMS), les structures MVC et d'autres outils ciblant un développement rapide. D'autres, comme Symfony et Zend, se concentraient davantage sur les modèles de conception d'entreprise et le commerce électronique.

Le bien et le mal de codeigniter

CakePhp et Codeigniter étaient les deux premiers cadres PHP qui étaient les plus ouverts sur la quantité d'inspiration tirée des rails. Codeigniter est rapidement passé à la gloire et en 2010 était sans doute le plus populaire des cadres PHP indépendants.

Codeigniter était simple, facile à utiliser et se vantait d'une documentation incroyable et d'une communauté forte. Mais son utilisation de la technologie et des modèles modernes progressait lentement, et à mesure que le monde du cadre a grandi et que l'outillage de PHP avançait, le codeigniter a commencé à prendre du retard en termes de progrès technologiques et de fonctionnalités prêtes à l'emploi.

Contrairement à de nombreux autres cadres, Codeigniter a été géré par une entreprise et ils ont été lents à rattraper PHP 5.Les fonctionnalités les plus récentes de 3 comme les espaces de noms et les mouvements vers GitHub et plus tard compositeur. C'est en 2010 que Taylor Otwell, Le créateur de Laravel, est devenu suffisamment insatisfait de Codeigniter qu'il a commencé à écrire son propre cadre.

Laravel 1, 2 et 3

La première version bêta de Laravel 1 a été publiée en juin 2011, et elle a été entièrement écrite à partir de zéro. Il comportait un orm personnalisé (éloquent); Routage basé sur la fermeture (inspiré par Ruby Sinatra); un système de module pour l'extension; et les aides pour les formulaires, la validation, l'authentification et plus.

Plus tard, Laravel 4 et Laravel 5 sont venus et ont changé tout le jeu.

Quoi de spécial chez Laravel?

Alors qu'est-ce que c'est qui distingue Laravel? Pourquoi vaut-il la peine d'avoir plus d'un cadre PHP à tout moment? Ils utilisent tous des composants de Symfony de toute façon, à droite? Parlons un peu de ce qui rend Laravel "Tick."

La philosophie de Laravel

Il vous suffit de lire le matériel marketing et les lectures de Laravel pour commencer à voir ses valeurs. Taylor utilise des mots liés à la lumière comme «illuminer» et «Spark.

Et puis il y a ces: «Artisans?' "Élégant?'Aussi, ceux-ci: «Breffe d'air frais." "Nouveau départ."Et enfin:" Rapid." "Vitesse de l'éclair.«Les deux valeurs les plus fortement communiquées du cadre sont d'augmenter la vitesse du développeur et le bonheur des développeurs.

Taylor a décrit la langue «artisan» comme contrastant intentionnellement avec des valeurs plus utilitaires. Vous pouvez voir la genèse de ce genre de réflexion dans sa question de 2011 sur StacKExchange (http: // bit.ly / 2dt5kms) dans lequel il a déclaré: «Parfois, je passe une quantité ridicule de temps (heures) angoissant sur la fait de rendre le code joli»- Juste pour une meilleure expérience de regarder le code lui-même.

Et il a souvent parlé de la valeur de faciliter et plus rapidement pour les développeurs de se concrétiser, de se débarrasser des obstacles inutiles à la création d'excellents produits. Laravel est, à la base, d'équiper et d'activer les développeurs. Son objectif est de fournir un code et des fonctionnalités clairs, simples et beaux qui aident les développeurs à apprendre, à démarrer et à développer et à écrire du code simple, clair et dureront.

Le concept de ciblage des développeurs est clair sur les matériaux Laravel. «Les développeurs heureux font le meilleur code» est écrit dans la documentation.

«Développeur Happiness From Download to Deploy» a été le slogan non officiel pendant un certain temps. Bien sûr, tout outil ou cadre dira qu'il veut que les développeurs soient heureux. Mais avoir le bonheur des développeurs comme principale préoccupation, plutôt que secondaire, a eu un impact énorme sur le style de Laravel et les progrès de la prise de décision. Lorsque d'autres cadres peuvent cibler la pureté architecturale comme objectif principal, ou la compatibilité avec les objectifs et les valeurs des équipes de développement d'entreprise, Laravel est l'accent principal sur le service du développeur individuel.

Comment Laravel réalise le bonheur du développeur

Dire simplement que vous voulez rendre les développeurs heureux est une chose. Le faire en est un autre, et cela vous oblige à vous demander ce qui dans un cadre est le plus susceptible de rendre les développeurs malheureux et ce qui est le plus susceptible de les rendre heureux. Il y a quelques façons dont Laravel essaie de faciliter la vie des développeurs.

Premièrement, Laravel est un cadre rapide de développement d'applications. Cela signifie qu'il se concentre sur une courbe d'apprentissage superficielle (facile) et sur la minimisation des étapes entre le démarrage d'une nouvelle application et la publication. Toutes les tâches les plus courantes dans la création d'applications Web, des interactions de base de données à l'authentification aux files d'attente en passant par e-mail à la mise en cache, sont simples par les composants que Laravel fournit.

Mais les composants de Laravel ne sont pas seulement parfaits seuls; Ils fournissent une API cohérente et des structures prévisibles sur l'ensemble du cadre. Cela signifie que, lorsque vous essayez quelque chose de nouveau dans Laravel, vous allez probablement finir par dire: «… et cela fonctionne juste?'

Cela ne se termine pas dans le cadre lui-même, non plus. Laravel fournit un écosystème entier d'outils pour construire et lancer des applications. Vous avez une propriété familiale et un valet de valet pour le développement local, une forge pour la gestion des serveurs et l'envoi pour un déploiement avancé.Et il y a une suite de packages complémentaires:

• Caissier - pour les paiements et les abonnements
• Echo - pour WebSockets
• Scout - pour la recherche
• Passeport - pour l'authentification de l'API
• Socialite - pour la connexion sociale
• Spark - pour bootstrap votre SaaS.

Laravel essaie de retirer le travail répétitif des emplois des développeurs afin qu'ils puissent faire quelque chose d'unique.

"Extraits de - Laravel Up & Running Book"