Le cache, les logs et le bootstrap cache seront disposés dans le dossier var/.

 La console est présente depuis le dossier bin/.

bin : les scripts de gestion symfony 3.

src : les bundles de votre projet.

var : les logs et le dossier de cache.

vendor : les bundles (vendors) externes.

web : les fichiers « publics » de votre projet.

La communauté Symfony s’oriente, peu à peu, vers une structure sans Bundle.

Vous pouvez conserver uniquement le bundle App pour votre projet.

Pour une vision simple et claire, vous pouvez utiliser une sous-arborescence reprenant les grands blocs fonctionnels de votre projet.

Command : Les commandes ou tâches vous permettent d’effectuer des traitements sur votre projet qui sont exécutés directement en ligne de commande.

Controller : Le controller contient les routers de votre application qui réalise le pont entre la « request » HTTP et la « response » HTTP renvoyée.

DataFixtures : Stocke les fixtures du projet (jeu de données).

Entity : Les déclarations de vos entités.

Repository : Les Repository gèrent les requêtes DQL ou SQL liées aux entités.

Listener : Les Listeners vous permettent d’exécuter du code lors d’un événement du déroulement des pages.

Form : Les formulaires de votre projet.

Service : Le code métier ou des traitements spécifiques. Les services permettent de centraliser du code qui pourrait être appelé par plusieurs controllers par exemple.

config : Ce dossier stocke vos déclarations de service, les paramétrages et la configuration de votre bundle au format yml (recommandé) ou xml.

public : Contient les assets comme vos images, vos feuilles de style et vos JavaScripts. Avec la gestion des assets Symfony, les éléments contenus dans ce dossier sont accessibles par tous.

views : pour gérer facilement vos templates, vous devez respecter l’arborescence de vos controllers. Pour le nommage des fichiers twig, simplifiez-vous la vie au maximum : index.html.twig, edit.html.twig, show.html.twig…

Si votre arborescence est bien conçue, ne rajoutez pas le nom de l’entité associé : show_post.html.twig.

. Les contrôleurs doivent être réalisés en respectant la règle « 5-10-20 »

– 5 variables maximum par méthode.

– 10 méthodes maximum par contrôleur.

– 20 lignes maximum par méthode.

. Une méthode est une agrégation d'appel à du code métier.

. Votre contrôleur doit étendre le contrôleur de base de FrameworkBundle et utiliser les annotations pour configurer le routage, le cache et la sécurité si c’est possible. Vous ne devez pas parcourir des dizaines de fichiers créés dans différents formats (YAML, XML, PHP).

. N’utilisez pas l’annotation @Template pour configurer le template utilisé par un contrôleur.

. Utilisez l’astuce du ParamConverter pour récupérer automatiquement une entité Doctrine quand c’est simple et pratique.

use AppBundle\Entity\Post;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;

/**
 * @Route("/{id}", name="admin_post_show")
 */
public function showAction(Post $post)
{
    $deleteForm = $this->createDeleteForm($post);

    return $this->render('admin/post/show.html.twig', array(
        'post'        => $post,
        'delete_form' => $deleteForm->createView(),
    ));
}

Stockez vos ressources dans le répertoire /web.

Utilisez Assetic pour compiler, combiner et compacter les ressources webs

Stockez les ressources web dans des dizaines de bundles différents rend leur gestion plus difficile.

A partir de Symfony 2.8, Assetic n'est plus inclus par défaut dans la version standard de Symfony. Donc il faut l'installer et l'activer dans votre application.

!!!?

, vous pouvez oublier l'utilisation d'Assetic.

C’est sont des outils côté client qui peuvent,  grâce à des modules, d’effectuer de nombreuses actions telle que la concaténation de fichiers, minification, compression d’image, compilation de LESS, TypeScript…

Contrairement à Assetic, vous devrez mettre en place certaines configurations mais rassurez-vous, cet investissement initial sera payant et au final bien plus rapide qu’Assetic.

Récemment, les technologies front comme AngularJS sont devenues populaires pour développer des applications web front qui communiquent avec une API.

Si vous développez une application de ce type, vous devriez utiliser les outils qui sont recommandés par ces technologies, comme Bower, GulpJS ...

​Vous devriez développer votre application front séparément de votre application back Symfony (Et même séparer les dépôts si vous voulez).

FOSJSRoutingBundle (Des routes dans votre JavaScript)

Son nom est assez évocateur, il permet d’exposer vos routes directement dans du code JavaScript. Cela signifie que vous serez en mesure de générer des URLs avec des paramètres donnés comme vous pouvez le faire avec le composant du routeur fourni dans le noyau Symfony.

LiipImagineBundle (Gestion des images)

Ne me dites pas que vous n’utiliserez pas d’images dans votre projet. Une photo de profil, une galerie photos… Autant de formats d’image, pas la peine d’afficher une image de 500px*500px si vous n’avez besoin que de l’afficher en 140px par 140px.

Avec LiipImagineBundle, définissez facilement directement dans le fichier de config vos formats et vos réglages : le Bundle s’occupe du reste.

KnpPaginatorBundle (Gestion des paginations)

Ce bundle est très pratique. En quelques lignes vous avez directement une pagination propre et efficace en place.

FOSRestBundle + JMSSerializerBundle  + NelmioApiDocBundle + LexikJWTAuthenticationBundle​ (Mise en place d'une API REST)

C'est un ensemble des bundles pour créer une API REST avec Symfony.

. FOSRestBundle pour mettre en place notre interface REST 

. JMSSerializerBundle pour sérialiser les données en json ou xml

. NelmioApiDocBundle pour l’interface de test et documentation de notre API

. LexikJWTAuthenticationBundle pour sécuriser notre API par un token

Gedmo Doctrine2 extensions (Manipulez des traductions avec Doctrine)

Lorsque l'on cherche à manipuler plusieurs traductions dans nos entités, nous arrivons rapidement sur l'extension Doctrine Gedmo Translatable, qui permet de manipuler très simplement et efficacement des traductions.

SonataSeoBundle (Manipulez des traductions avec Doctrine)

Très simplement, nous avons la main sur les métas (robots, title, og:image….) de chaque page via leur controller respectif. Il est très simple à mettre en place et répond a beaucoup de besoins SEO front office.