Доброго времени суток, уважаемые хабравчане. Сегодня увидел статью на хабре «Официальный гайд по лучшим практикам в Symfony» и понял, что мне есть что исправить добавить. К вашему вниманию список личных советов и объяснение к ним.
Лично я люблю аннотации, но с опытом понял, что они приносят некий дискомфорт. Дело в том, что всю конфигурацию перенести в аннотации нельзя. Остается 2 варианта:
Если выбрать второй вариант, то при росте проекта получается каша. И в вашем коде аннотаций больше, чем логики. Отговорки по типу «так легче находить роуты» не принимаются. Так как если расскидывать файлы конфигураций правильно, ты всегда знаешь, где находятся роуты к определённым контроллерам. Я уже молчу про команды в консоли, по типу route:debug, и отладчик, в котором видно название екшена и имя роута.
Плохой пример (как по мне):
Сразу приведу плохой пример, как устроено на текущем проекте:
Все классы менеджеров должны быть в папке Manager, классы репозиториев Repository. Если этого не делать, то при появлении уже 5-10 сущностей со своими менеджерами и репозиториями жить становится «веселее».
Всё просто. В каждой отдельной странице вы сможете переопределять и подгружаться будут всегда только те яваскрипты и стили, которые нужны. Так же советую в самом базовом шаблоне эти блоки оставить пустыми. А в бандлах при создании главного layout.html.twig их заполнять.
Даже если проект небольшой, изначально привыкайте хранить конфигурации бандлов в AppBundle/Resources/, а не в app/config. В app/ только ссылки. В основном это касается роутинга и сервисов.
Сущности лучше описывать в конфигурации, например, в AppBundle/Resources/config/doctrine/Entity.orm.yml, и генерить с помощью команды doctrine:generate:entities, которая сама сгенерирует классы сущностей. Когда конфиги сущностей находятся в файлах, сами классы выглядят чище. Так же вы будете уверенны, что в них нет ошибок.
В файле parameters.test укажите параметры тестовой базы, в которую загружаете фикстуры. Так вы всегда будете уверенны, что тестируете одни и те же данные. Возможно, все так и делает, просто на текущем проекте я столкнулся с отсутствием такой практики.
Конечно это всё банальные вещи, но есть люди, которые так не делают и из-за этого страдаютмученики программисты, которые пишут после них.
Буду рад если кто-то напишет свои советы в комментариях.
Добавленно:
Используйте по меньше аннотаций
Лично я люблю аннотации, но с опытом понял, что они приносят некий дискомфорт. Дело в том, что всю конфигурацию перенести в аннотации нельзя. Остается 2 варианта:
- Максимум в файлах конфигурации ( например yml);
- Немножко в файлы, немножко в аннотации.
Если выбрать второй вариант, то при росте проекта получается каша. И в вашем коде аннотаций больше, чем логики. Отговорки по типу «так легче находить роуты» не принимаются. Так как если расскидывать файлы конфигураций правильно, ты всегда знаешь, где находятся роуты к определённым контроллерам. Я уже молчу про команды в консоли, по типу route:debug, и отладчик, в котором видно название екшена и имя роута.
Плохой пример (как по мне):
Менеджеры и репозитории выносить в отдельные папки
Сразу приведу плохой пример, как устроено на текущем проекте:
Все классы менеджеров должны быть в папке Manager, классы репозиториев Repository. Если этого не делать, то при появлении уже 5-10 сущностей со своими менеджерами и репозиториями жить становится «веселее».
В шаблонах всегда определяйте блоки с яваскриптом и стилями
Всё просто. В каждой отдельной странице вы сможете переопределять и подгружаться будут всегда только те яваскрипты и стили, которые нужны. Так же советую в самом базовом шаблоне эти блоки оставить пустыми. А в бандлах при создании главного layout.html.twig их заполнять.
Конфигурации бандлов хранить в AppBundle/Resources
Даже если проект небольшой, изначально привыкайте хранить конфигурации бандлов в AppBundle/Resources/, а не в app/config. В app/ только ссылки. В основном это касается роутинга и сервисов.
Entity описывать в файле конфигурации
Сущности лучше описывать в конфигурации, например, в AppBundle/Resources/config/doctrine/Entity.orm.yml, и генерить с помощью команды doctrine:generate:entities, которая сама сгенерирует классы сущностей. Когда конфиги сущностей находятся в файлах, сами классы выглядят чище. Так же вы будете уверенны, что в них нет ошибок.
Для тестов создавайте отдельную базу
В файле parameters.test укажите параметры тестовой базы, в которую загружаете фикстуры. Так вы всегда будете уверенны, что тестируете одни и те же данные. Возможно, все так и делает, просто на текущем проекте я столкнулся с отсутствием такой практики.
Конечно это всё банальные вещи, но есть люди, которые так не делают и из-за этого страдают
Буду рад если кто-то напишет свои советы в комментариях.
Добавленно:
- Регистрировать форм типы в DI, а не создавать через new (Иначе не работают form type extensions) — to0n1
- Использовать lazy прокси для зависимостей в twig extension (Иначе строится полное дерево зависимостей на каждый request) — to0n1
- По возможности не использовать трейты совместно с кофигами в аннотациях (нет возможности перекрыть аннотации в классе использующем трейт) — to0n1
