web-dev-qa-db-fra.com

Symfony 4: comment organiser la structure des dossiers (à savoir, votre logique métier)

Dans le Symfony Best Practices est conseillé de ne pas utiliser de bundles pour organiser la logique métier.

Les bundles doivent être utilisés uniquement lorsque le code qu'ils contiennent est destiné à être réutilisé tel quel dans d'autres applications:

Mais un bundle est censé être quelque chose qui peut être réutilisé en tant que logiciel autonome. Si UserBundle ne peut pas être utilisé "tel quel" dans d'autres applications Symfony, il ne doit pas s'agir de son propre ensemble.

Donc, alors que je mets à jour mon application de Symfony 3.3 vers Symfony 4, je pense que c'est le bon moment pour réorganiser mon code.

En ce moment, j'ai suivi la "structure groupée":

- src
   - AppBundle
      - Controller
      - Entity
      - Repository
      - Resources
      - ...
   - MyNamespace
      - Bundle
          - BundleTodo
              - Controller
              - Entity
              - Repository
              - Resources
              - ...
          - BundleCatalog
              - Controller
              - Entity
              - Repository
              - Resources
              - ...
          - BundleCart
              - Controller
              - Entity
              - Repository
              - Resources
              - ...
          - ...

Maintenant, avec la nouvelle structure de répertoires, comment dois-je organiser mon code?

Je voudrais l'organiser de cette façon:

-src
   - Core
      - Controller
      - Entity
      - Repository
      - ..
   - Todos
      - Controller
      - Entity
      - Repository
      - ..
   - Catalog
      - Controller
      - Entity
      - Repository
      - ..
   - Cart
      - Controller
      - Entity
      - Repository
      - ...

Mais est-ce exact? Y a-t-il un problème avec la structure de dossiers attendue de Symfony 4 et Flex?

Ou vaut mieux quelque chose comme ça:

-src
   - Controller
       - Core
       - Todos
       - Catalog
       - Cart
       - ...
   - Entity
       - Core
       - Todos
       - Catalog
       - Cart
       - ...
   - Repository
       - Core
       - Todos
       - Catalog
       - Cart
       - ...
   - ...

La même chose s'applique également aux autres dossiers racine comme décrit dans structure du répertoire du projet (sur la façon de le remplacer).

Y a-t-il des règles ou des contraintes que je dois prendre en compte pour décider de ma nouvelle structure de dossiers?

ESSAYER DE RÉSOUDRE LE PROBLÈME

Donc, en essayant de résoudre le problème, je vais plus loin dans la documentation et j'écrirai ici ce que je vais trouver.

symfonysymfony4
23
Aerendir

Comme indiqué dans les commentaires, Symfony peut bien fonctionner avec toutes ces structures, donc en effet nous ne pouvons pas avoir de réponse acceptée ici, mais voici mes deux cents.

Pour être honnête, la meilleure pratique serait d'organiser l'architecture indépendamment du framework (c'est principalement pour cette raison que Symfony 4 n'impose plus de bundle).

Mais en fait, sauf pour des projets vraiment spécifiques ou complexes, il sera plus pratique d'avoir une organisation "orientée symfony".

Ce qui suit est mes préférences personnelles, et sont également fortement influencées par la typologie de mes projets (orienté CRUD, API Rest, sans logique métier forte)

En général, je m'oriente vers une structure comme celle-ci:

-src
   - Controller
       - Core
       - Todos
       - ...
   - Entity
       - Core
       - Todos
       - ...
   - Repository
       - Core
       - Todos
   - Validator (or other Symfony oriented components)
       - Core
       - Todos
   - Others (depend on project)
       - Core
       - Todos
   - ...

Les raisons sont les suivantes:

  • Moins de définition de service avec autowire - ouais, je suis paresseux ;-)

    Si vous devez enregistrer vos référentiels ou contrôleurs en tant que services, vous pouvez le faire avec une seule déclaration.

  • Dans les recettes Symfony Flex, c'est généralement cette structure qui est utilisée.

    DoctrineBundle par exemple initialiser src/Entity et src/Repository les dossiers et recettes contenant des entités utilisent également cette structure.

Mais gardez à l'esprit que Symfony Flex n'est pas obligatoire. Son but est principalement de faciliter le démarrage du projet et de rendre le cadre plus accessible au débutant

8
j-guyon

La 2ème structure est tout à fait appropriée pour les applications complexes, les secteurs d'activité sont divisés.
Il est facile avec Symfony 4 de configurer son application de cette façon.

├─ assets/
├─ bin/
│  └─ console
├─ config/
│  ├─ doctrine/ 
│  │    ├─ core/
│  │    └─ sample/
│  ├─ packages/
│  ├─ routes/
│  └─ validator/
│  │    ├─ core/
│  │    └─ sample/
├─ public/
│  └─ index.php
├─ src/
│  ├─ Core/         
│  │  ├─ Controller/
│  │  ├─ Entity/
│  │  ├─ Repository/
│  │  └─ ...
│  ├─ Sample/      
│  └─ ...
├─ templates/
│  ├─ core/
│  └─ sample/
├─ tests/
├─ translations/
├─ var/
│  ├─ cache/
│  ├─ log/
│  └─ ...
└─ vendor/

Avec un peu de configuration: service auto-câblage, auto-configuration etc ... fonctionne comme un charme.

# config/packages/doctrine.yaml
doctrine:
    # ...
    orm:
        # ...
        auto_mapping: true
        mappings:
            App\Core:
                is_bundle: false
                type: yml
                dir: '%kernel.project_dir%/config/doctrine/core'
                prefix: 'App\Core\Entity'
                alias: 'AppCore'


#config/routes/annotations.yaml
core_controllers:
    resource: ../../src/Core/Controller/
    type: annotation


# config/services.yaml
# But I prefer to put this on a separate config/services/_auto.yaml
services:
    App\:
        resource: '../../src/*/*'
        exclude: '../../src/*/{Entity,Migrations,Tests,Kernel.php}'

    app_controller:
        namespace: App\
        resource: '../../src/*/Controller'
        tags: ['controller.service_arguments']
6
Benito103e

Loi de Conway:

les organisations qui conçoivent des systèmes ... sont contraintes de produire des conceptions qui sont des copies des structures de communication de ces organisations.

Vous devez concevoir votre structure de répertoires autour de la façon dont vous organisez le travail.

Si vous ou vos collègues travaillez sur une pile complète par fonctionnalité, vous devez regrouper votre code par fonctionnalité. Cela facilitera la navigation et la découverte de code.

Si vous ou vos collègues êtes bien spécialisés dans le back-end, le front-end, les traductions, etc., vous devez organiser votre code autour de cela. La structure du répertoire par fonction permettra une répartition claire des responsabilités.

De plus, la profondeur devrait dépendre de la taille que vous prévoyez pour un projet. Si ce sera un effort de plus de 5 ans de plus de 5 personnes, vous devriez probablement aller de pair avec la fonction par fonction et par fonction avec l'imbrication, comme mentionné, en fonction de l'organisation du travail. Si ce sera un projet de 3 mois pour une personne, c'est-à-dire un outil interne simple, vous devriez probablement opter pour une structure plus plate. Je recommanderais également de s'en tenir aux valeurs par défaut.

De plus, j'ai trouvé cet article informatif: https://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/

6
Isinlor