Symfony 4: Как организовать структуру папок (а именно, вашу бизнес-логику)

Ответ 1

Как отмечалось в комментариях, Symfony может хорошо работать со всеми этими структурами, так что, действительно, у нас здесь не может быть принятого ответа, но вот мои два цента.

Если честно, передовой практикой будет организация архитектуры независимо от фреймворка (в основном по этой причине Symfony 4 больше не навязывает пакет).

Но на самом деле, за исключением действительно конкретных или сложных проектов, будет более практично иметь организацию, ориентированную на symfony.

Далее следуют мои личные предпочтения, на которые также сильно влияет типология моих проектов (CRUD-ориентированный, Rest API, без сильной бизнес-логики).

В общем, я двигаюсь к такой структуре:

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

Причины:

• Меньше определения сервиса с autowire - да, я ленивый ;-)

  Если вам нужно зарегистрировать свои репозитории или контроллеры как сервисы, вы можете сделать это с помощью одной декларации.

• В рецептах Symfony Flex обычно используется именно эта структура.

  DoctrineBundle, например, инициализирует папки и рецепты src/Entity и src/Repository которые содержат сущности, также используют эту структуру.

Но помните, что Symfony Flex не является обязательным. Его цель в основном состоит в том, чтобы облегчить инициацию проекта и сделать структуру более доступной для начинающих

Ответ 2

2-я структура вполне подходит для сложного приложения, бизнес-сферы разделены.
С Symfony 4 легко настроить свое приложение таким образом.

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

С небольшой настройкой: сервисная автоподстройка, автоконфигурация и т.д. Работают как шарм.

# 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']

Ответ 3

Закон Конвея:

организации, которые разрабатывают системы... вынуждены производить проекты, которые являются копиями коммуникационных структур этих организаций.

Вы должны разработать свою структуру каталогов вокруг того, как вы организуете работу.

Если вы или ваши коллеги работаете с полным стеком для каждой функции, вы должны сгруппировать свой код для каждой функции. Это облегчит навигацию и обнаружение кода.

Если вы или ваши коллеги хорошо разбираетесь в серверной части, интерфейсе, переводах и т.д., Вы должны организовать свой код вокруг этого. Структура каталогов для каждой функции будет поддерживать четкое распределение обязанностей.

Кроме того, глубина должна зависеть от того, насколько большой проект вы предвидите. Если это будет 5+ лет работы 5+ человек, вы, вероятно, должны пойти с разделением на функции и функции с вложением, как уже упоминалось, в зависимости от организации работы. Если это будет трехмесячный проект для одного человека, т.е. какой-то простой внутренний инструмент, вы, вероятно, должны использовать более плоскую структуру. Я также рекомендовал бы придерживаться значений по умолчанию.

Кроме того, я нашел эту статью информативной: https://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/