Монолитная структура в бездыме Symfony 4
Я начал использовать и тестировать Symfony 4 для миграции основного проекта. Я привык к тому, что Symfony рассказывал о том, как файлы должны быть структурированы, но теперь, когда нет больше пакетов, я задаюсь вопросом, как структурировать огромное монолитное приложение.
Масштаб теперь: ~ 300 маршрутов, ~ 70 контроллеров, ~ 90 объектов, ~ 20 пакетов
Как должен выглядеть services.yaml? — я должен остаться в пространстве имен приложения или, может быть, я мог бы имитировать пакеты? Где разместить конфигурацию сервиса для каждого компонента?
Как службы и контроллеры должны быть разделены в каталогах? — Должен ли я пойти на src/Service/{Something}/{Something}Manager.php или остаться на src/{Something}/Service/{Something}Manager.php и просто не использовать ключевое слово Bundle? Зачем?
Где бы вы поместили UserAuthenticationProvider и / или WebSocketServer?
Решение
Я создал новый набор REST API для устаревшего монолитного приложения и столкнулся с теми же вопросами.
Сначала я отвечу на этот вопрос:
Как службы и контроллеры должны быть разделены в каталогах?
Я спустился src/Service/{Something}/{Something}Manager.php путь, как я думал, что это был путь. Поскольку проект вырос, я сожалею об этом и буду двигаться к src/{Something}/Service/{Something}Manager.php
Зачем?
- Я нахожу разделение в пространстве имен намного проще для чтения и намного
сложнее случайноuseнеправильный класс. - Теперь у меня есть файлы, распределенные по всему приложению, и намного сложнее абстрагировать их в библиотеку, которая может быть повторно использована другими приложениями.
- Я не могу так легко изменить функциональность — все
переплетены. Если бы я преобразовывал монолит, я бы предпочел иметь
код для рефакторинга, который был связан с какой-то функцией, чтобы я мог работать над
что, прежде чем перейти к следующему.
Есть и другие причины, но они чувствуют необходимость отделить это, прежде чем приложение станет больше.
Как должен выглядеть services.yaml? Ну, автопроводка потрясающая. Я бы оставил ваши сервисные блоки в различных функциональных разделениях (как указано выше) и начал бы их рефакторинг. С конфигурацией автоматической проводки по умолчанию вы обнаружите, что очень мало нуждается в явных определениях.
Где бы вы поместили UserAuthenticationProvider и / или WebSocketServer?
Для провайдера, наверное, что-то вроде src/Security/Authentication/Provider/UserAuthenticationProvider.php,
Для сервера WS я не совсем уверен — это зависит от того, где он находится в приложении и как он используется.
Другие решения
Начнем с того, что S4 по-прежнему поддерживает пакеты, как и прежде. Секция config была немного реорганизована, но если у вас уже есть огромное приложение, работающее под пакетами, вы можете просто оставить его более или менее как есть. Это все еще должно работать просто отлично с минимальной настройкой.
Есть несколько подходов для приложения без пакета. Обычно вы группируете файлы по функциям, используя подкаталоги функций, чтобы упорядочить вещи.
Предположим, у вас есть три существующих пакета, называемые FooBundle, BarBundle, JarBundle
config
services
foo.yaml
bar.yaml
jar.yaml
routes:
foo.yaml
bar.yaml
jar.yaml
src
Controller
Foo
Foo1Controller
Foo2Controller
Bar
etc
Entity
Foo
foo entities
Bar
bar entities
Form
etc
templates
foo
bar
jar
Вы поняли идею. Возможно, стоит смоделировать все это заранее, особенно, чтобы увидеть, где шансы и концы могут соответствовать. И, вероятно, использовать пространство имен приложения для всего. Этот подход в значительной степени соответствует рекомендациям Symfony 4. На самом деле не могу пойти далеко не так с этим.
Существует по крайней мере еще один подход, при котором файлы группируются по функциям. Я не буду вдаваться в подробности, так как это определенно не обычный подход Symfony и потребует некоторых настроек. Но вы могли бы сделать:
src
Blog
routes.yaml
services.yaml
BlogEntity.php
BlogVoter.php
Edit
BlogEditController.php
BlogEditForm.php
BlogEditTemplate.html.twig
etc
Show
BlogShowController.php
etc
detector