Symfony 4: cómo organizar la estructura de carpetas (es decir, la lógica de su negocio)

Solución:

La segunda estructura es bastante adecuada para aplicaciones complejas, áreas comerciales divididas.
Con Symfony 4 es fácil configurar su aplicación de esta manera.

├─ 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/

Con un poco de configuración: servicio de cableado automático, configuración automática, etc … funcionan como un encanto.

# config/packages/doctrine.yaml
doctrine:
    # ...
    orm:
        # ...
        auto_mapping: true
        mappings:
            AppCore:
                is_bundle: false
                type: yml
                dir: '%kernel.project_dir%/config/doctrine/core'
                prefix: 'AppCoreEntity'
                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']

Ley de Conway:

las organizaciones que diseñan sistemas … están obligadas a producir diseños que sean copias de las estructuras de comunicación de estas organizaciones.

Debe diseñar la estructura de su directorio en torno a cómo organiza el trabajo.

Si usted o sus colegas trabajan en una pila completa por función, debe agrupar su código por función. Facilitará la navegación y el descubrimiento de códigos.

Si usted o sus colegas están bien especializados en back-end, front-end, traducciones, etc., deberían organizar su código en torno a eso. La estructura del directorio por función apoyará una clara división de responsabilidades.

Además, la profundidad debería depender de qué tan grande prevé que sea un proyecto. Si será un esfuerzo de más de 5 años de más de 5 personas, probablemente debería dividir tanto por función como por función con anidación, como se mencionó, dependiendo de la organización del trabajo. Si va a ser un proyecto de 3 meses para una persona, es decir, una herramienta interna simple, probablemente debería optar por una estructura más plana. También recomendaría ceñirse a los valores predeterminados.

Además, encontré este artículo informativo: https://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/

Como se indicó en los comentarios, Symfony puede funcionar bien con todas estas estructuras, por lo que, de hecho, no podemos tener una respuesta aceptada aquí, pero aquí está mi granito de arena.

Para ser honesto, las mejores prácticas serían organizar la arquitectura independientemente del framework (es principalmente por esta razón que Symfony 4 ya no impone un paquete).

Pero de hecho, a excepción de proyectos realmente específicos o complejos, será más práctico tener una organización “orientada a Symfony”.

Lo que sigue son mis preferencias personales, y también están fuertemente influenciados por la tipología de mis proyectos (Orientado a CRUD, API Rest, sin una lógica empresarial sólida)

En general, me estoy moviendo hacia una estructura como esta:

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

Las razones son:

• Menos definición de servicio con autowire, sí, soy vago 😉

  Si necesita registrar sus repositorios o controladores como servicios, puede hacerlo con una declaración.

• En las recetas de Symfony Flex, normalmente se utiliza esta estructura.

  DoctrineBundle, por ejemplo, inicializar src/Entity y src/Repository las carpetas y recetas que contienen entidades también utilizan esta estructura.

Pero tenga en cuenta que Symfony Flex no es obligatorio. Su propósito es principalmente facilitar el inicio del proyecto y hacer que el marco sea más accesible para los principiantes.

---

---

Utiliza Nuestro Buscador