Spécialiste Programmation Web Symfony

 

 

Cadre de travail Symfony


Symfony est un framework PHP gratuit permettant de développer rapidement des applications web et de gérer les tâches courantes des développeurs web. Son développement et son soutien sont sponsorisés par la société française Sensio.Symfony consiste en un ensemble de composants déconnectés qui peuvent être réutilisés dans des projets.

De nombreux grands projets ont été développés avec Symfony :

-Systèmes de gestion de contenu : Magento, Drupal, Opencart
-service de bookmarking social Delicious
-Le site français d'hébergement de vidéos Dailymotion
-moteur de forum phpbb

Par exemple, Symfony a influencé le développement du cadre Laravel à l'aide de ses composants.

Symfony permet d'installer des paquets, des bibliothèques, des composants et des personnalisations de tiers en les configurant dans des fichiers YAML, XML, PHP et .env.

Symfony ne fournit pas de composant de base de données, mais il offre une intégration étroite avec la bibliothèque Doctrine.

Symfony fournit une fonction de programme de messagerie basée sur la populaire bibliothèque Swift Mailer. Ce mailer prend en charge l'envoi de messages depuis vos propres serveurs de messagerie ainsi que depuis des fournisseurs de messagerie populaires tels que Mandrill, SendGrid et Amazon SES.

Un moteur d'internationalisation vous permet de définir et de traduire les messages des applications Web en fonction de la langue ou du pays de votre choix.

Symfony offre un système de journalisation des erreurs d'application ainsi que la possibilité de connecter la bibliothèque de journalisation Monolog.

Les avantages :


1.Puissant écosystème autour du cadre, avec une bonne communauté et de nombreux développeurs.

2.Une documentation de qualité et constamment mise à jour pour toutes les versions du cadre.

3.Beaucoup de composants différents sans rapport entre eux, à réutiliser.

4. Offre un mécanisme de test fonctionnel et unitaire pour trouver les bogues dans les applications web.

5. Convient aux projets web complexes et chargés.


Cons:


Malgré une bonne documentation, le cadre est difficile à apprendre. 

 

Que savons-nous de Symfony ? Mythes et légendes


Merci à notre développeur web Artem Kartasov pour son aperçu des avantages et inconvénients de Symfony !

Lorsqu'on interroge un développeur web sur Symfony, il a généralement une certaine image en tête, une certaine idée fixe. Que peut-on dire de Symfony en une phrase ? Il s'agit d'un framework web complet écrit en PHP. C'est vrai, mais ce n'est pas une définition exacte. L'idée de Symfony est un peu plus large que la définition standard. Symfony est un ensemble de composants autonomes. Les composants s'interconnectent pour former une plateforme web, un écosystème. Le choix des composants dépend toutefois de vous et de vos objectifs. Vous pouvez également utiliser un ensemble minimal pour créer une application ou un prototype simple, ou déployer ce framework Symfony tout-en-un. Dans cet article, nous allons surtout examiner Symfony du point de vue du framework.

Lors de nos entretiens avec des développeurs PHP, nous avons mis en évidence certains points clés communs et nous nous sommes demandé si tout est aussi (bon/mauvais) qu'on le dit.

Mythes et légendes de Symfony

- Faible connectivité des composants


La modularité est l'une des caractéristiques les plus importantes du travail avec Symfony. Comme déjà mentionné, Symfony est une collection de composants réutilisables et autonomes, appelés bundles. Dans Symfony, tout est un bundle et tout vit dans des bundles, aussi bien les composants du noyau du framework que le code de votre application. Cette architecture vous permet de construire votre application de manière très flexible. En construisant votre application brique par brique, votre application n'est plus un mur monolithique et vous ne devez pas démonter toute l'application pour remplacer un module. Et bien sûr, vous pouvez personnaliser la configuration finale. De plus, vous pouvez utiliser des composants Symfony individuels en dehors du cadre. D'autres projets tels que Laravel, Drupal, Magento et bien d'autres ont également adopté cette approche avec succès.

Bien sûr, nous devrions également mentionner le support de l'injection de dépendances dans Symfony comme l'une des principales caractéristiques du cadre. L'utilisation du DI réduit la connectivité et simplifie les tests du code.

- Il existe de nombreuses solutions prêtes à l'emploi dans Symfony.


C'est vrai, il existe des solutions pour de nombreuses tâches différentes, des plus banales aux plus exotiques. Il existe plus de 2500 bundles, chacun d'entre eux pouvant être branché et utilisé, grâce à la modularité. Si, pour une raison quelconque, l'une des liasses ne convient pas, elle peut être remplacée par une liasse similaire, il y a l'embarras du choix. Ou, en corrigeant la faille fatale et en réalisant un rêve cher à un programmeur, vous pouvez écrire le vôtre - le même, mais différent. Il est peut-être formidable de pouvoir réutiliser des composants prêts à l'emploi et des bibliothèques tierces, sans pour autant être lié à une technologie ou un outil particulier.

- Symfony est compliqué

Symfony est trop complexe. C'est en partie vrai parce que Symfony a un seuil de connexion plus élevé que les autres frameworks PHP. Par rapport à d'autres frameworks, Symfony prend un peu plus de temps à maîtriser. Ce ne sera pas facile pour les nouveaux arrivants. Ici et l'utilisation de fonctionnalités innovantes du langage, et l'utilisation de design patterns. Vous devez être prêt à apprendre plus que Symfony. En outre, vous devriez découvrir les technologies et les outils qui vont de pair avec Symfony pour le rendre aussi utile que possible : Twig, SwiftMailer, Monolog, phpUnit, Doctrine, et les bundles les plus populaires tels que FOS, Knp, Gedmo, et autres.

- Symfony est très bien conçu


Symfony se définit par un concept et une idéologie bien définis, mais il est important de comprendre qu'il ne fournit pas une solution "taille unique". La tâche de créer l'architecture finale de l'application (n'oublions pas de respecter les normes) est entièrement déléguée au développeur et laissée à lui-même. Cela a deux implications qui se chevauchent : un développeur Symfony expérimenté est plus susceptible d'avoir une connaissance approfondie du langage en particulier et des compétences de conception en général. Sur une note moins réjouissante, il est plus difficile de trouver un développeur Symfony compétent et il faut du temps pour former le sien.

- Symfony vous garde libre

Vous pensez que vous avez branché le paquet et que vous êtes prêt à partir ? Attendez une seconde, ce n'est pas si simple. Comme le cadre est flexible, il existe de nombreuses possibilités de le personnaliser. Les configurations et les annotations sont tout pour nous. Le framework est déjà livré avec les fichiers de configuration de base. Mais les développeurs de Symfony ne se limitent pas aux fichiers yaml. Vous pouvez utiliser des annotations, des configurations et des fichiers xml ou php pour configurer votre application ou des parties de celle-ci. Il n'y a pas de style unifié, et chacun utilise le moyen le plus pratique. Bien sûr, pour de nombreux points, il existe des recommandations sur ce qu'il faut utiliser dans telle ou telle situation, mais cela n'impose pas de restrictions supplémentaires aux développeurs, ils sont libres de faire leur propre choix.

Qu'est-ce que c'est - la liberté ou le chaos ? Cette situation peut être retournée dans les deux sens. C'est assez simple. En donnant le choix aux gens, vous leur donnez des responsabilités. Il est évident que si elle est utilisée sans précaution, l'application se transformera facilement en une courtepointe en patchwork, et la qualité du produit ne sera pas élevée. La bonne solution consiste à convenir au sein de l'équipe d'une approche de la configuration de l'application et de la description du code avant même le début de la phase active de développement. La communication est la clé du succès.

- Symfony ne convient qu'aux grands projets

Question compliquée. Symfony, si nous parlons d'un framework complet, est bon pour les projets relativement importants. Je serais probablement d'accord pour dire que Symfony n'est pas toujours le meilleur choix pour les petits projets, à quelques exceptions près. Tout d'abord, il peut être utilisé lorsqu'un projet relativement générique doit être résolu, et que les gains d'un démarrage rapide et de bundles standard sont considérables. Toutefois, dans ce cas, ce choix doit être fait consciemment, en pesant les avantages ainsi que les problèmes que l'on pourrait rencontrer. Utiliser Symfony pour une petite API (vous pouvez vous tourner vers des micro-frames tels que Silex) ou un simple site web, c'est comme aller faire ses courses dans un camion long courrier - oui, ça marche, mais c'est plus lent et plus cher qu'une camionnette. La deuxième exception est l'utilisation de Symfony comme outil de croissance pour étendre votre projet et le rendre évolutif. Dans tous les cas, vous devez choisir un outil en fonction de vos objectifs, et non l'inverse.

- Symfony est lent


Je ne qualifierais pas Symfony de lent. Pour les besoins de cet article, nous ne mesurerons pas les performances, nous n'avons pas une telle tâche, mais je crois qu'il est facile de trouver les benchmarks du framework php. Les résultats sont très convaincants, même si Symfony n'est pas le framework préféré, il en existe d'autres plus rapides. Il est important de comprendre pourquoi il en est ainsi. Tous les avantages que nous obtenons en travaillant avec Symfony nécessitent des ressources, et l'abstraction n'est pas gratuite. Tout se paie, et en programmation, nous devons souvent payer la convivialité, la qualité et la rapidité des performances.

Cela soulève immédiatement une question litigieuse : qu'est-ce qui est le plus cher - le coût du développement ou les coûts d'hébergement ? À mon avis, il est plus facile d'ajouter un serveur, augmentant ainsi les performances de l'application, que de trouver et d'ajouter un nouveau développeur au projet. Bien sûr, cela ne signifie absolument pas que vous ne devez pas penser à l'optimisation du produit et à la performance finale. Vous devez et il est très important de toujours tenir compte de cet aspect. Je ne vous cacherai pas que l'optimisation des performances n'est pas une tâche facile. Vous devez comprendre ce qui se passe en interne et comprendre en détail ce qui pourrait causer le ralentissement et comment gérer la charge.

- Trop de magie

J'entends souvent dire qu'il y a trop de magie dans Symfony et que l'on ne sait pas toujours d'où viennent les choses et, surtout, comment elles fonctionnent. Je ne peux pas vraiment être d'accord avec ça. Il n'y a pas plus de magie dans Symfony que dans n'importe quel autre framework. L'utilisation de tout cadre implique un certain niveau de "magie". C'est normal. L'un des objectifs d'un framework est de simplifier les tâches répétitives. Lorsque vous commencez à travailler avec un framework, vous utilisez des exemples de documentation, des recettes toutes faites. En même temps, certaines choses peuvent ne pas être aussi évidentes, être incompréhensibles, nous appelons souvent cela de la magie. Vous utilisez la magie du cadre, et tout semble aller bien. À un certain point, vous ressentez le manque de fonctionnalités et de recettes standard du framework, il est temps de créer votre "magie". En créant votre magie, vous comprenez comment le cadre fonctionne réellement, et à ce moment précis, cette partie cesse d'être une boîte noire pour vous, et cette fonctionnalité cesse d'être magique pour vous. C'est ainsi que la maîtrise du cadre se fait. Vous n'avez pas à craindre de ne pas comprendre tous les détails tout de suite.

- Une communauté puissante


Cet argument peut être entendu en parlant de presque tous les frameworks ou langages de programmation plus ou moins populaires. Tout le monde est convaincu que la communauté est massive, extrêmement amicale, réactive et prête à faire du bien à chaque nouveau venu. Aussi cliché que cela puisse paraître, la communauté Symfony est en fait à grande échelle. Il y a beaucoup de développeurs sur github et stackoverflow qui répondent aux questions (cela inclut les développeurs du noyau et du shell). De plus, la communication n'est pas à sens unique ; tout le monde peut créer des demandes de tirage, faire des suggestions, créer ses propres paquets. Les amateurs de communication en direct doivent savoir que la communauté organise régulièrement des conférences internationales et nationales.

- Soutien et financement

Un autre point important pour un projet open-source qui n'est pas toujours mis en avant est le soutien d'une société commerciale, dans ce cas SensioLabs. L'entreprise propose des services complémentaires tels que le conseil, la formation, les différentes certifications. Cela donne une confiance supplémentaire en termes de stabilité du projet, de croissance et de développement de l'écosystème du cadre.

- Bonne documentation


Il faut noter le haut niveau de la documentation, elle est pertinente pour chaque version du framework, elle décrit non seulement les composants, mais aussi les bundles les plus populaires. Jusqu'à récemment, le site officiel contenait un livre sur l'utilisation pratique de Symfony, une liste de recettes et de bonnes pratiques pour utiliser le framework. À l'occasion du cinquième anniversaire de la deuxième version du framework, ses créateurs ont décidé de remanier en profondeur la documentation, en créant deux sections : Getting started - un petit livre sur les bases du framework et Guides - des guides sur plusieurs sujets. Malheureusement, tous les documents susmentionnés ne sont pas disponibles en russe, et ce fait peut être mentionné comme un obstacle supplémentaire pour les débutants. N'ayez pas peur, cependant - la documentation est bien structurée, écrite dans un langage clair et simple, avec des exemples de code et est facile à comprendre.

Symfony ne limite pas vos choix, il vous donne de la flexibilité mais exige en même temps une compréhension approfondie de son fonctionnement et responsabilise la structure de votre application.

Toute l'essence des annotations Symfony est contenue dans un seul contrôleur :

/**
 * @Route("/{id}/", requirements={"id":"\d+"})
 * @Method("GET")
 * @Rest\View(statusCode=200, serializerEnableMaxDepthChecks=true, serializerGroups={"details"})
 * @ParamConverter("user", class="AppBundle:User")
 * @ApiDoc(
 *   description="Fetch info of a user",
 *   requirements={
 *      {
 *          "name"="id",
 *          "dataType"="integer",
 *          "requirement"="\d+",
 *          "description"="User id"
 *      }
 *   },
 *   resource=true,
 *   section="User"
 * )
 */
public function getUserAction(User $user)
{
	return $user;
}

Principales différences entre Laravel et Symfony

PRINCIPALES DIFFÉRENCES ENTRE LARAVEL ET SYMFONY

À l'ère du grand nombre de frameworks PHP, les développeurs PHP sont souvent confrontés à la question suivante : quel framework utiliser pour leurs projets ?

Beaucoup sont déjà indécis, ayant trouvé ce qui leur convient le mieux, et pour certains il est difficile de déterminer la réponse.

Voyons et comparons certaines caractéristiques de frameworks aussi populaires que Symfony et Laravel.

Installation du Frameworks


Les fichiers de base des frameworks PHP modernes peuvent être installés à l'aide du gestionnaire de paquets Composer.

Ainsi, pour Laravel, cela peut être fait avec la commande composer create-project --prefer-dist laravel/laravel nom_du_projet pour Symfony composer create-project symfony/website-skeleton nom_du_projet, où nom_du_projet est le nom du projet et en même temps le nom du répertoire créé où composer placera les fichiers du framework.

En même temps, les deux systèmes ont maintenant leur propre installateur, laravel nouveau nom de projet et symfony nouveau nom de projet, et les installateurs eux-mêmes peuvent être installés en exécutant une seule ligne : composer global require laravel/installer et wget https://get.symfony.com/cli/installer -O - | bash respectivement.

Vous pouvez ainsi constater que le processus d'installation de la fonctionnalité minimale est réduit au minimum et prend très peu de temps.

Mise en place


Les deux frameworks prennent désormais en charge un fichier de configuration .env qui stocke des paires clé-valeur, mais Symfony prend également en charge les fichiers yaml pour la configuration du routage, des services et autres.

Le format yaml est très utile et vous permet de spécifier les valeurs de configuration d'une manière qui ressemble à un tableau multidimensionnel.

Routage


Chaque framework a sa propre façon de spécifier les routes d'application et de les lier aux contrôleurs. Ainsi, pour spécifier dans Laravel que la route "/test" doit être traitée par la méthode TestController, vous devez spécifier ce qui suit dans le fichier de routage routes/api.php : Route::get('/test', '[email protected]')->name('test_name') ; Pour Symfony, on peut faire de même avec les fichiers yaml responsables du routage ou, plus commodément, avec les annotations .

namespace App\Controller;

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class TestController {

    /**
     * @Route("/test", name="test_name")
     */
    public function test() {
         return new Response('Some test text');
    }
}

 

 

 

L'utilisation de contrôleurs présente un grand nombre d'avantages. Ainsi, dans le chemin d'accès "/test", vous pouvez spécifier des paramètres dynamiques, par exemple "/test/{id}". Maintenant vous devez spécifier le paramètre $id dans la signature du contrôleur, et sa valeur sera tirée du chemin. Vous pouvez également formater les paramètres dynamiques à l'aide d'expressions régulières. Ainsi, par exemple, $id est uniquement un nombre entier. En outre, chaque cadre dispose d'une fonctionnalité permettant de combiner les routes en groupes et de leur attribuer des préfixes, d'attribuer des méthodes HTTP par lesquelles ces routes seront disponibles et de fournir un support pratique pour les paramètres GET et POST.

Migrations et ORM


Les deux systèmes offrent un ensemble utile de commandes de console pour les migrations de projets, mais la principale différence entre Laravel et Symfony réside peut-être dans leur mode de fonctionnement. Dans Laravel, nous devons créer des migrations par nous-mêmes, et nous devons aussi garder la structure de notre base de données et les classes PHP synchronisées.
Ainsi, par exemple, le code de migration ressemblerait à ceci

Schema::create('tests', function (Blueprint $table) {
$table->bigIncrements('id') ;
}) ;


et la classe Test ressemblera à ceci

namespace App;

use Illuminate\Database\Eloquent\Model;

class Test extends Model
{
    protected $table = 'tests';
}


Comme vous pouvez le constater, tous les modèles de Laravel héritent de la classe Model.
Dans Symfony, en revanche, vous travaillez avec les migrations par le biais de l'ORM Doctrine. Ici, nous ne pouvons travailler qu'avec des classes et des annotations PHP.
Ainsi, un exemple de code pour la classe Test ressemblerait à ceci

 

namespace App\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity()
 */
class Test
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer")
     */
    private $id;
}

 


Après avoir créé l'entité Test, nous pouvons commencer à créer une migration où Symfony crée lui-même le code SQL exécutable pour créer la table des tests avec la colonne id. De plus, nous n'avons pas besoin de maintenir la structure de la base de données et les classes PHP aussi soigneusement que possible, car lors de la création des migrations, le framework compare la structure actuelle de la base de données avec celle attendue sur la base des classes PHP actuelles et génère tout le SQL nécessaire.

Il est intéressant de noter que les deux frameworks fournissent des ORM pour l'analyse des bases de données. Dans Laravel, c'est Eloquent qui s'en charge. Ainsi, par exemple, le code ci-dessous permet d'obtenir une collection d'objets de la classe Test :

$tests = App\Test::where('id', '<', 100)
   ->orderBy('id', 'desc')
               ->take(10)
               ->get();


Dans Symfony, ce type de code fréquemment utilisé est déplacé vers des classes spéciales de dépôt, tandis que le corps de la méthode elle-même ressemble à ceci

$tests = $this->createQueryBuilder('t')
            ->where('t.id < :id')
            ->setParameter('id', 100)
            ->orderBy('t.id', 'DESC')
            ->setMaxResults(10)
            ->getQuery()
            ->execute();


Dans ce cas, il retournera un tableau d'objets de la classe Test, et l'ORM de Doctrine s'en chargera.
Eloquent et Doctrine mettent tous deux en œuvre le modèle de conception Fluent Interface, comme vous pouvez le voir d'après les noms des méthodes where, orderBy et autres. 

Si vous êtes familier avec l'un des moteurs de création de modèles, vous comprendrez l'autre sans trop de difficultés. En ce qui concerne le front-end, Laravel prend également en charge Vue.js, ce qui ouvre des possibilités supplémentaires, mais dans le web d'aujourd'hui, il n'est pas impossible d'utiliser n'importe quel framework back-end PHP en combinaison avec un framework front-end JavaScript tel que React, Angular ou Vue.js. En conclusion, parmi les deux grands frameworks, Laravel et Symfony, vous ne pouvez pas choisir le meilleur, mais seulement celui qui répond le mieux à vos besoins spécifiques. Bien qu'elles mettent en œuvre des stratégies différentes pour créer l'application web résultante, aucune des deux implémentations ne peut être qualifiée de mauvaise. Les deux frameworks vous permettent d'étendre considérablement les fonctionnalités de base en fonction de vos besoins, et le grand nombre de paquets installés avec composer ne fait qu'y contribuer. Laravel et Symfony peuvent tous deux être utilisés aussi bien pour les petits sites que pour les sites d'entreprise, notamment en raison des systèmes de mise en cache intégrés et des hautes performances. Chacun d'entre eux est potentiellement extensible, de sorte qu'une fois que vous avez choisi un cadre pour un nouveau projet, c'est à vous de décider de son extensibilité.