Как обновить приложение Symfony 3 до пакета Symfony 4 без пакета?
В разделе Обновление существующих приложений до Flex, документация Symfony 4 гласит:
- Переместить исходный код из
src/{App,...}Bundle/вsrc/и обновить пространства имен каждого файла PHP, чтобы бытьApp\...(продвинутые IDE могут сделать это автоматически).
Первая часть «Переместить исходный код из src/{App,...}Bundle/« ясно. Мы можем понять структуру каталогов следующим образом:
sf3-project/
├── src/
├── AppBundle/
├── Controller/
├── MyFirstController.php
└── MySecondController.php
└── ...
└── ApiBundle/
├── Controller/
├── MyFirstController.php
└── MySecondController.php
└── ...
Тем не менее, вторая часть «в src/ и обновить пространства имен каждого файла PHP, чтобы быть App\...« мне неясно, особенно о предлагаемой структуре.
Как я понял, он предлагает скопировать содержание каждого Controller/ каталог в одном каталоге. Если да, то как быть с контроллерами с одинаковыми именами? Должны ли мы добавить подкаталоги с префиксом предыдущего пакета в качестве имени?
демонстрационный проект Symfony кажется, предлагает это, из-за Admin/ каталог под Controller/,
Как мы должны обновить предыдущую структуру каталогов до следующей?
sf4-project/
├── src/
├── Controller/
│ └── ...
├── ...
└── Kernel.php
Мы можем заметить это SF4-проект пример следует пакет за слоем структура, как в документации. Мне также интересно, если мы можем легко использовать пакет по функции состав.
Итак, каковы рекомендуемые способы с Symfony 4 для обоих пакет за слоем а также пакет по функции структуры?
Решение
Symfony и связки
Symfony 2 упомянул: «Связки — это граждане 1-го класса в рамках Symfony». Таким образом, это был немного самоуверенный фреймворк, где все было в комплекте, даже ваше приложение.
Позже хорошие практики рекомендовали, чтобы пакет был только повторно используемыми компонентами вашего приложения, но мы продолжаем использовать пакеты для всего, что нужно для организации кода.
Это привело к тому, что многие разработчики постоянно повторяют структуру пакетов по умолчанию, игнорируя то, что будет работать для них лучше. Просто потому, что это помогает вам не думать об архитектуре, вы запускаете команду, которая генерирует всю структуру папок и контроллеров.
Если вы посмотрите на (хорошо спроектированные, совместимые с другими фреймворками) пакеты Symfony, то обнаружите, что в них есть как минимум 2 пакета. Один с кодом, классами, сервисами и т. Д. И другой пакет, который настраивает все это в Symfony. Примеры: Doctrine, jms / serializer, KnpMenu и т. Д.
Связки меньше Symfony
Я считаю, что цель перехода на пачку менее symfony:
- Простое повторное использование с другими фреймворками: Laravel, Silex ?, Zend
- Заставьте задуматься и спроектируйте лучшую архитектуру для проекта, который вы пытаетесь решить.
Поэтому отойти от пакетов Symfony и скопировать именно то, что имеет новая версия Symfony в качестве архитектуры по умолчанию / demo, вам совсем не поможет.
Мой совет: забудьте настройки по умолчанию / рекомендуемые настройки Symfony 4
Спланируйте, как вы должны организовать свой код: определите ваши пакеты и библиотеки и где разместить ваш код, чтобы его было легко разрабатывать, поддерживать и тестировать.
Попробуйте свести к минимуму ваши зависимости между пакетами и библиотеками.
Решите свои собственные компромиссы, а затем, если вам нужно рефакторинг, сделайте это.
Если вы не хотите планировать свою собственную архитектуру или хотите сделать это позже, не проводите рефакторинг.
Посмотрите видео дяди Боба об архитектуре программного обеспечения: https://www.youtube.com/watch?v=HhNIttd87xs
Другие решения
Других решений пока нет …