По ходу прочтения “Symfony best practices”
Originally published at ostretsov.ru. You can comment here or there.
Здесь кое-какие замечания по ходу чтения Symfony best practices. Я уже читал этот мануал по диагонали. На этот раз решил пройтись по нему внимательнее: от корки до корки.
Один генеральный (AppBundle) бандл на весь проект
Это очень удобно, если проект на неделю-две, но большие проекты, которые поддерживаешь годами хочется разбить на логические бандлы. Просто так удобнее ориентироваться в коде спустя какое-то время. В текущем проекте пока только 284 класса, разнесенных на 6 логических бандлов. Представляю какой бы это был огород, если бы все классы лежали в AppBundle.
4 глава, бизнес-логика
Понравилось замечание по именованию сервисов. Я до сих пор использую имена вроде sp_event.request_form.builder.field_collection_builder. В гайдбуке рекомендуют не извращаться и придумывать лаконичные имена. С этим полностью согласен. Писать подобные вызовы сервисов слишком ugly:
$this->getContainer()->get('sp_event.request_form.builder.field_collection_builder')->...;
Использование Yaml’а для определения сервисов. Да, он более читаем и короток. Мне больше по душе XML. Разницы с точки зрения производительности нет, поэтому это больше вопрос вкуса. В следующем проекте попробую Yaml.
Полезно было вспомнить вот про этот проект: https://github.com/fabpot/PHP-CS-Fixer. Это про приведение кода проекта к PSR-стандарту оформления. За несколько секунд на выходе получаем красивый код. Дешево и красиво.
Странно, что в гайдбуке инициализируют массив по-старому: array(), хотя PHP 5.4 вышел более двух лет назад.
Упомянут был хороший md2html парсер.
Глава 7, формы
Это мой любимый компонент. Всегда использовал проверку
if ($form->isValid()) { // do sth... }
Для красоты оформления и читаемости кода рекомендуют еще предварить условие $form->isSubmitted() проверкой. Ок, согласен, красивый код - один из моих приоритетов при разработке.
Для трансляций рекомендуют использовать XLIFF формат. Мне он кажется менее удобным, чем YAML, но действительно для профессиональных переводчиков поддерживается немало редакторов, работающих именно с XLIFF. Еще надо бы попробовать JMSTranslationBundle в каком-нибудь проекте. Действительно удобный бандл?
Показалось разумным выносить трансляции в глобальную область видимости (app/Resources/translations).
Узнал кое-что про подбор паролей с помощью радужных таблиц. Если используется соль (salt) для усложнения конечного хеша пароля, то взломать такой пароль кроме как брут-форсом невозможно (возможно конечно, но неоправдано дорого).
Глава 9, security
Я не сторонник использования ACL в виде готового решения от Sensio. Если он нужен, то я делаю свой на базе воутеров. Пока что это было оправдано даже в очень сложных проектах со сложной иерархией ролей (например, было 5 acl_* таблиц; для каждого пользователя создавался граф привелегий и кешировался в Redis; наличие привелегии проверялось в воутере). Недавно (месяца 3 назад) вышел замечательный Expression-компонент и он изумительно скрещивается с Security компонентом (и ParamConverter’ом конечно же) для проверки привелегии в аннотации подобным образом:
/** * @Route("/{id}/edit", name="admin_post_edit") * @Security("is_granted('edit', post)") */ public function editAction(Post $post) { // sth
Красиво. Лаконично. От этого невозможно отказаться.
Глава 10, assets
Да, надо след проект заточить на Grunt/gulp. Ради интереса :).
От себя бы еще добавил обязательность регулярной проверки бандлов в продакшене:
bin/console security:check