Монолитная структура в бездымном Symfony 4 - PullRequest
Новая
       24

Монолитная структура в бездымном Symfony 4

0 голосов
/ 15 мая 2018

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

Масштаб: ~ 300 маршрутов, ~ 70 контроллеров, ~ 90 объектов, ~ 20 пакетов

Как должен выглядеть services.yaml? - я должен оставаться в пространстве имен приложения или, возможно, я мог бы имитировать пакеты? Где разместить конфигурацию сервиса для каждого компонента?

Как службы и контроллеры должны быть разделены в каталогах? - Должен ли я перейти на src/Service/{Something}/{Something}Manager.php или остаться на src/{Something}/Service/{Something}Manager.php и просто не использовать ключевое слово Bundle? Почему?

Куда бы вы поместили UserAuthenticationProvider и / или WebSocketServer?

Ответы [ 2 ]

0 голосов
/ 15 мая 2018

Я создал новый набор REST API для устаревшего монолитного приложения и столкнулся с теми же вопросами.

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

Я пошел по пути src/Service/{Something}/{Something}Manager.php, так как думал, что это путь. Поскольку проект вырос, я сожалею об этом и буду двигаться к src/{Something}/Service/{Something}Manager.php

Почему?

  1. Я считаю, что разделение в пространстве имен намного легче читать и намного сложнее случайно use неправильный класс.
  2. Теперь у меня есть файлы, разбросанные по всему приложению, и намного сложнее абстрагировать их в библиотеку, которая может быть повторно использована другими приложениями.
  3. Я не могу так просто изменить функциональность - все переплетены. Если бы я преобразовывал монолит, я бы предпочел иметь код для рефакторинга, который был связан с какой-то функцией, чтобы я мог работать над что, прежде чем перейти к следующему.

Существуют и другие причины, но они чувствуют необходимость отделить их, прежде чем приложение станет больше.

Как должен выглядеть services.yaml? Ну, автопроводка потрясающая. Я бы оставил ваши сервисные блоки в различных функциональных разделениях (как указано выше) и начал бы их рефакторинг. С конфигурацией автоматической проводки по умолчанию вы обнаружите, что очень мало нуждается в явных определениях.

Куда бы вы поместили UserAuthenticationProvider и / или WebSocketServer?

Для провайдера, наверное, что-то вроде src/Security/Authentication/Provider/UserAuthenticationProvider.php.

Для сервера WS я не совсем уверен - это зависит от того, где он находится в приложении и как он используется.

0 голосов
/ 15 мая 2018

Начнем с того, что 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
...