Recherche…


Introduction

Exemples et bonnes pratiques pour configurer votre application Symfony qui ne figurent pas dans la documentation officielle.

Inclure tous les fichiers de configuration d'un répertoire

Après un certain temps, vous obtenez de nombreux éléments de configuration dans votre config.yml. Il peut vous rendre la configuration plus facile à lire si vous divisez votre configuration sur plusieurs fichiers. Vous pouvez facilement inclure tous les fichiers d'un répertoire de cette manière:

config.yml:

imports:
    - { resource: parameters.yml }
    - { resource: "includes/" }

Dans le includes répertoire que vous pouvez mettre par exemple doctrine.yml, swiftmailer.yml, etc.

Utiliser le nom de classe complet (FQCN) comme identifiant de service

Dans de nombreux exemples, vous trouverez un identifiant de service tel que "acme.demo.service.id" (une chaîne avec des points). Votre services.yml ressemblera à ceci:

services:
    acme.demo.service.id:
        class: Acme\DemoBundle\Services\DemoService
        arguments: ["@doctrine.orm.default_entity_manager", "@cache"]

Dans votre contrôleur, vous pouvez utiliser ce service:

$service = $this->get('acme.demo.service.id');

Bien qu'il n'y ait pas de problème avec cela, vous pouvez utiliser un nom de classe pleinement qualifié (FQCN) comme identifiant de service:

services:
    Acme\DemoBundle\Services\DemoService:
        class: Acme\DemoBundle\Services\DemoService
        arguments: ["@doctrine.orm.default_entity_manager", "@cache"]

Dans votre contrôleur, vous pouvez l'utiliser comme ceci:

use Acme\DemoBundle\Services\DemoService;
// ..
$this->get(DemoService::class);

Cela rend votre code plus compréhensible. Dans de nombreux cas, cela n'a aucun sens d'avoir un identifiant de service qui n'est pas seulement le nom de la classe.

A partir de Symfony 3.3, vous pouvez même supprimer l'attribut class si votre identifiant de service est un FQCN.

Aucune interface HTTP nécessaire?

Si votre application n'a besoin d'aucune interface HTTP (par exemple pour une application uniquement console), vous souhaiterez désactiver au moins Twig et SensioFrameworkExtra

Juste commenter ces lignes:

app / AppKernel.php

$bundles = [
//...
//    new Symfony\Bundle\TwigBundle\TwigBundle(),
//    new Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(),
//...
if (in_array($this->getEnvironment(), ['dev', 'test'], true)) {
//...
//    $bundles[] = new Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();

app / config / config.yml

framework:
#    ...
#    router:
#        resource: '%kernel.root_dir%/config/routing.yml'
#        strict_requirements: ~
#    ...
#    templating:
#        engines: ['twig']
#...
#twig:
#    debug: '%kernel.debug%'
#    strict_variables: '%kernel.debug%'

app / config / config_dev.yml

#framework:
#    router:
#        resource: '%kernel.root_dir%/config/routing_dev.yml'
#        strict_requirements: true
#    profiler: { only_exceptions: false }

#web_profiler:
#    toolbar: true
#    intercept_redirects: false

Vous pouvez également supprimer les exigences de fournisseur connexes de composer.json :

"sensio/framework-extra-bundle": "x.x.x",
"twig/twig": "x.x"

L'utilisation de Symfony dans un tel cas est discutable, mais au moins cela peut être temporaire.



Modified text is an extract of the original Stack Overflow Documentation
Sous licence CC BY-SA 3.0
Non affilié à Stack Overflow