Contenu
Demandez-moi quel framework utiliser et je vais probablement avoir un moment de vieille femme grincheux et vous dire que tous les frameworks sont aussi mauvais les uns que les autres. Ce qui ne veut pas dire qu'ils sont tous mauvais, exactement, mais en PHP, nous avons un nombre inimaginable de frameworks (généralement cités comme N + 1, où N est le nombre de développeurs PHP dans le monde), et ils ont probablement tous un sens à la personne qui les a inventés.
Avoir un choix de frameworks est probablement mieux que d'essayer de n'utiliser qu'un seul framework, quel que soit exactement ce que vous essayiez de créer, car c'est le «meilleur» (quelle que soit la mesure du «meilleur»). Cette sélection d'offres de cadre signifie que vous pouvez choisir quelque chose qui répond aux besoins du projet et cela peut même être documenté. Les cadres sur n'importe quelle plate-forme sont vraiment là pour fournir une structure, des modules et des bibliothèques réutilisables, et évitent généralement toutes les tâches ennuyeuses et répétitives liées à la création répétée de la même fonctionnalité. Par exemple, lors de la création de CMS, quelque chose devrait traiter et valider les champs de formulaire pour moi; si je suis laissé à moi-même, il se peut que je passe à côté de quelque chose d'important et je préfère de loin faire les éléments de chaque projet qui sont différent, plutôt que ceux qui sont les mêmes à chaque fois!
Framework full-stack
Les frameworks full-stack, tels que Zend Framework, peuvent être un bon point de départ pour un développeur sans beaucoup d'expérience en architecture. Cela donne une bonne structure pour accrocher une nouvelle application, et il y a un bon «écosystème» autour de lui - beaucoup de livres, de tutoriels et une documentation raisonnable aussi. Si vous essayez de créer une application volumineuse qui sera maintenue par de nombreuses personnes, un cadre complet et populaire sera probablement un bon choix car il dictera beaucoup de structure et sera bien connu et compris.
Avoir une structure pour aider à la séparation est toujours bon; au début de ma carrière, j'ai travaillé avec certains très développeurs juniors et a tenté de leur enseigner le modèle MVC (Model View Controller), qui était relativement nouveau à l'époque. Nous avons pris la décision d'utiliser Smarty dans la couche de vue; en partie pour que les concepteurs puissent travailler plus facilement avec les modèles, et en partie pour que quelqu'un vienne à mon bureau et me dise "comment faire X avec Smarty?" Je pourrais dire "ne faites pas X dans la vue!" (neuf fois sur 10, c'était la réponse). Avoir des frameworks nous aide à trouver la même séparation dans d'autres parties de notre application. Beaucoup d'entre eux prennent en charge l'intégration à une couche de modèles telle que Smarty ou mon nouveau favori, Twig, vous pouvez donc emporter ces outils avec vous, quel que soit le cadre de votre choix.
Alléger la charge
Il existe de nombreux frameworks plus légers que Zend Framework, par exemple je travaille un peu avec CodeIgniter. Est-il aussi complet et robuste que Zend Framework? Non, ce n’est pas le cas. Mais en tant que cadre d’aide permettant de créer rapidement une application, c’est utile. En général, les frameworks avec moins de fonctionnalités "d'aide" peuvent être plus faciles à trouver car il est beaucoup plus évident de savoir comment les éléments vont ensemble. Dans un cadre inconnu (pour moi, c'est à peu près tout), ce sont les éléments automagiques qui compliquent le travail et le débogage.
Ce sentiment d'être «perdu dans un nouveau cadre» est inévitable et totalement frustrant; même un développeur expérimenté se sent comme un débutant quand il ne sait pas comment quelque chose fonctionne. Si vous n’êtes vraiment pas chanceux, vous aurez choisi un framework dont le canal IRC vous dira que vous êtes également idiot! C'est cette expérience initiale très négative qui dissuade de nombreuses personnes d'utiliser un nouveau framework ou d'en adopter un en premier lieu, et très peu de frameworks réussissent bien à aider les nouveaux utilisateurs à surmonter cet obstacle initial.
En PHP, nous avons également des frameworks qui ne sont pas vraiment des frameworks comme j'utilise habituellement le mot. Nous avons de jolis cadres de composants; collections de bibliothèques conçues pour être utilisées à volonté et pour bien jouer ensemble, telles que Zeta Components (anciennement eZ Components) et Symfony Components (avez-vous vu leur site? Ils remportent le prix de la meilleure œuvre d'art!). Le meilleur et le plus sous-jacent de ceux-ci est, bien sûr, les propres offres PEAR et PECL de PHP - elles sont en quelque sorte oubliées dans ce nouveau monde courageux de frameworks.
Microframeworks
Les microframeworks sont une tendance émergente en PHP; ce sont des offres ultra-légères qui vous aident simplement à coller les choses ensemble plus rapidement. Un bon exemple est Slim, qui est très rapide et simple à utiliser, et comprend les concepts RESTful. Il est basé sur l’idée de «routes», qui sont des modèles d’URL. Vous enregistrez une route et donnez un rappel qui doit être appelé lorsque cette URL est demandée.
La plupart des développeurs PHP adoptent un framework et s'en tiennent à lui, ou ils peuvent en utiliser un au travail et un autre pour leurs projets de passe-temps ou open source. Il y a peu de consensus sur le "meilleur" framework à utiliser, donc tout le monde s'en tient à ce qu'il sait et le résultat est le développement parallèle d'un nombre massif de frameworks! J'adore avoir un choix parmi lesquels choisir, mais ai-je mentionné qu'ils sont tous aussi mauvais les uns que les autres?
Si vous connaissez Zend Framework, vous finissez par vous décrire comme un développeur Zend Framework; vous ne seriez pas à l'aise d'écrire dans un autre framework tant que vous n'auriez pas eu l'occasion de vous y familiariser, et vous ne vous souviendrez probablement pas de la plupart des fonctions PHP brutes si vous ne les utilisez pas souvent. Cette idée que nous sommes devenus des développeurs spécifiques au framework, ne travaillant que sur des couches d'abstraction, est un peu étrange pour PHP. Après tout, c'est le langage "pour résoudre le problème du Web". Il est écrit en C et est un langage rapide et léger en soi ... à condition que vous n’attendiez pas qu’un processus d’amorçage à grande échelle s’exécute! De ce contexte a émergé le Manifeste MicroPHP, écrit par un homme que nous appelons Funkatron (bien que son nom soit en réalité Ed Finkler). C’est une série de déclarations disant qu’il est normal de créer un certain nombre de petits modules interopérables, que plus gros n’est pas meilleur, et qu’en réalité, la vie est trop courte pour Java - même si elle est écrite en PHP.
