Поскольку я новичок в Symfony и начиная с версии 4.2, у меня была та же проблема, что и у @DeveloperMobile.

Структура каталогов

Это моя структура каталогов, основанная на рекомендациях Руководства Symfony Best Practices версии 4.2.

Рекомендация в основном говорит о строении:

• Поместите все контроллеры в / src / Controller, разделив их подпапками
• Не используйте пакеты, организуйте свой код по пространствам имен
• Поместите активы, конфигурацию, тесты, шаблоны, переводы, var / cache и var / log в корневую папку
• Организуйте свою бизнес-логику в / src
• Используйте автоматическое подключение, чтобы автоматизировать настройку сервисов приложений.
• Используйте внедрение зависимостей для получения сервисов
• Тонкие контроллеры и толстая модель

Итак, в основном это говорит: да, вы можете организовать свой код в / src с помощью подпапок, но код с определенной функциональностью, такой как контроллер, сущность, форма, репозиторий и т. Д., Должен находиться в конкретном каталоге.

Выполнение

root/
├─ assets/
├─ bin/
│  └─ console
├─ config/
└─ public/
│  └─ index.php
├─ src/
   ├─ Controller/
     ├─ DefaultController.php
     ├─ ...
     ├─ Api/
     │   ├─ ..
     │   └─ ..
     ├─ Backend/
     │   ├─ ..
     │   └─ ..
   ├─ Entity/
   ├─ Form/
   ├─ Repository/
   ├─ Twig/
   ├─ Utils/
   └─ Kernel.php
├─ tests/
├─ templates/
├─ translations/
├─ var/
│  ├─ cache/
│  └─ log/
└─ vendor/

Лучшая практика Symfony 4.2

Это список всех рекомендаций по ссылке выше:

Установка

• Используйте Composer и Symfony Flex для создания приложений Symfony и управления ими.
• Используйте Symfony Skeleton для создания новых проектов на основе Symfony.

Структура

• Не создавайте никаких пакетов для организации логики вашего приложения.

  (Приложения Symfony по-прежнему могут использовать сторонние пакеты (установленные в vendor /) для добавления функций, но вы должны использовать пространства имен PHP вместо пакетов для организации собственного кода.)

Конфигурация

• Определите параметры конфигурации, связанные с инфраструктурой, как переменные среды. Во время разработки используйте файлы .env и .env.local в корне вашего проекта, чтобы установить их.

• Определите все переменные env вашего приложения в файле .env

• Определите параметры конфигурации, связанные с поведением приложения, в файле config / services.yaml.
• Используйте константы для определения параметров конфигурации, которые редко меняются.
• Имя ваших параметров конфигурации должно быть как можно короче и должно включать общий префикс для всего приложения.

Бизнес-логика

Для большинства проектов весь код следует хранить в каталоге src /. Здесь вы можете создавать любые каталоги, которые хотите организовать:

• Используйте автоматическое подключение, чтобы автоматизировать настройку сервисов приложений.
• Идентификатор служб вашего приложения должен быть равен имени их класса, за исключением случаев, когда у вас есть несколько служб, настроенных для одного и того же класса (в этом случае используйте идентификатор случая змеи).
• По возможности службы должны быть частными. Это предотвратит доступ к этой службе через $ container-> get (). Вместо этого вам нужно будет использовать внедрение зависимостей.
• Используйте формат YAML для настройки ваших собственных сервисов.
• Используйте аннотации для определения информации о отображении сущностей Doctrine.

Контроллеры

• Сделайте так, чтобы ваш контроллер расширил базовый контроллер AbstractController, предоставляемый Symfony, и по возможности используйте аннотации для настройки маршрутизации, кэширования и безопасности.
• Не добавляйте суффикс Action к методам действий контроллера.
• Не используйте аннотацию @Template для настройки шаблона, используемого контроллером. -Не используйте $ this-> get () или $ this-> container-> get () для получения сервисов из контейнера. Вместо этого используйте внедрение зависимостей.
• Используйте уловку ParamConverter для автоматического запроса сущностей Doctrine, когда это просто и удобно.

Шаблоны

• Используйте для своих шаблонов формат Twig.
• Сохраните шаблоны приложений в каталоге templates / в корне вашего проекта.
• Используйте snake_case в нижнем регистре для имен каталогов и шаблонов.
• Используйте префикс подчеркивания для частичных шаблонов в именах шаблонов.
• Определите свои расширения Twig в каталоге src / Twig /. Ваше приложение автоматически обнаружит их и настроит.

Формы

• Определите свои формы как классы PHP.
• Поместите классы типов форм в пространство имен App \ Form, если вы не используете другие настраиваемые классы форм, такие как преобразователи данных.
• Добавляйте кнопки в шаблоны, а не в классы форм или контроллеры.
• Не определяйте ограничения проверки в форме, а на объекте, которому сопоставляется форма.

Интернационализация

• Сохраните файлы переводов в каталоге translations / в корне вашего проекта.
• Используйте формат XLIFF для файлов перевода.
• Всегда используйте ключи для переводов вместо строк содержимого.

Безопасность

• Если у вас нет двух законно разных систем аутентификации и пользователей (например, форма входа в систему для основного сайта и система токенов только для вашего API), мы рекомендуем иметь только одну запись брандмауэра с включенным анонимным ключом.
• Используйте кодировщик bcrypt для хеширования паролей пользователей.
• Определите настраиваемого избирателя безопасности для реализации детальных ограничений.

Веб-активы

• Храните свои активы в каталоге assets / в корне вашего проекта.
• Используйте Webpack Encore для компиляции, объединения и минимизации веб-ресурсов.

Тесты

• Определите функциональный тест, который хотя бы проверяет, успешно ли загружаются страницы вашего приложения.
• Жестко закодируйте URL-адреса, используемые в функциональных тестах, вместо использования генератора URL.

Как говорится (источник), вы определяете свою собственную структуру, не рекомендуется проводить рефакторинг всего вашего фактического приложения.

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

Надеюсь, ты получил ответ :)

Каждый большой проект должен быть разделен на backend, frontend и api или services, и между ними должен быть ключ переменной формата, ключ кода ошибки и управление ключом кеша, поэтому каждый проект должен иметь собственную зависимость, сокращать время обслуживания, час разработки, и т.д ...

backend.mysite.com

www.mysite (frontend)

api.mysite.com

Как сказал @Nelson, нет необходимости реорганизовывать ваше текущее приложение.

Если это для нового проекта, вы можете делать то, что хотите.

Например, вы можете сделать свои контроллеры такими

src
   - Controller
      - Bundle1 //Bundle is not the right word here, it's just to say you can separate your code in independents parts like this
      - Bundle2

То же самое для логических классов, моделей (сущность / документ) и т. Д. И т. Д.

Вам просто нужно изменить файл services.yaml, чтобы указать, где находятся ваши контроллеры, и определить, в каких папках у вас есть службы (классы для инъекций) и т. Д.

Вы в основном можете делать все, что захотите, даже если рекомендуется следить за их демонстрационным приложением (src/controller/*, src/Form/* и т. Д.)

Вопрос старый, и я надеюсь, что он вам все еще поможет.