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

В Symfony Best Practices рекомендуется не использовать пакеты для организации бизнес-логики.

Связки должны использоваться только тогда, когда код в них предназначен для повторного использования как есть в других приложениях:

Но пучок должен быть чем-то, что можно использовать повторно автономной части программного обеспечения. Если UserBundle нельзя использовать "как есть" в другие приложения Symfony, то это не должно быть его собственным пакетом.

Итак, когда я обновляю свое приложение от Symfony 3.3 до Symfony 4, я думаю, что сейчас самое подходящее время для реорганизации моего кода.

В настоящий момент я следил за "связкой-структурой":

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

Теперь, с новой структурой каталогов, как мне организовать код?

Я хотел бы организовать его так:

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

Но, это правильно? Есть ли проблемы с ожидаемой структурой папок Symfony 4 и Flex?

Или лучше что-то вроде этого:

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

То же самое относится и к другим корневым папкам, как описано в структуре каталога проекта (о том, как переопределить его).

Существуют ли какие-либо правила или ограничения, которые я должен учитывать при выборе моей новой структуры папок?

ПЫТАЯ РЕШИТЬ ПРОБЛЕМУ

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


Ответ 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/