Лучшие практики Symfony (официальная рекомендация)

Несколько дней назад Фабьен Потенсье через Sensio представил электронную книгу, в которой собраны лучшие практики и рекомендации по разработке проекта Symfony. Составленный на основе рекомендаций, размещенных сообществом, цель этого документа — дать набор советов, связанных с ph.iloСофия из Symfony. Я постараюсь кратко обобщить 31 совет, описанный на английском языке в этом посте.

Введение

Этот документ начинается с некоторых советов и нескольких предложений, призванных вдохновить нас этим документом.

«Этот документ не является учебным пособием»

Этот документ был написан для всех разработчиков Symfony. И знатоки, и новички.

«Не рефакторинг ваших приложений»

В самом начале документа специально объясняется, что после прочтения мы не должны обновлять и реорганизовывать наши приложения, чтобы они идеально соответствовали многочисленным рекомендациям Sensio. Поэтому мы можем сразу сделать ссылку на первые идеи, разработанные в документе: эти хорошие практики должны позволить нам упростить нашу жизнь, а также упростить проверку кода. В поддержку моих замечаний выдвигаются три причины:

• Ваши существующие приложения не являются ошибочными, они просто следуют другому набору рекомендаций;
• Полный рефакторинг кодовой базы может привести к ошибкам в ваших приложениях;
• Объем работы, потраченный на это, может быть лучше направлен на улучшение ваших тестов или добавление функций, которые представляют реальную ценность для конечных пользователей.

Создать проект

В главе 2, посвященной тому, как объявить и создать проект Symfony, дается первая «лучшая практика»:

_Всегда используйте Композитор. _Composer представил основы современного PHP через разрешение зависимостей. Благодаря ему зависимости прописались в файле composer.json будет разрешен и репатриирован в ваш проект, чтобы его можно было использовать. Кроме того, можно легко обновлять.

Таким образом, вы можете уважать структурную организацию проекта Symfony. (см. стр. 8).

Exemples:

• приложение/кэш будет хранить кеш;
• приложение/журналы хранить журналы;
• приложение / Ресурсы будет хранить шаблоны, а также глобальные переводы для вашего приложения;
• SRC / хранить пакеты приложений;
• продавец / хранить зависимости вашего проекта;
• Интернет / будет хранить активы (css, js, изображения и т. д.), а также передний файл (app.php), что позволит вам впоследствии перенаправить ваши запросы на ваши контроллеры.
  В итоге новая рекомендация по комплектациям. Без проведения моего собственного анализа, который мог бы поставить под сомнение philosophie из Symfony (чего я не хочу), вот рекомендация:

Создайте один пакет AppBundle для приложения. Это связано с тем, как был разработан Symfony. Каждый пакет должен быть _stand-alone. _Поэтому они должны иметь возможность жить автономно и независимо.

Я оставляю вас поразмышлять над этой рекомендацией…

Конфигурация

В третьей главе даются советы по настройке его применения. Некоторые элементы конфигурации могут отличаться от системы разработки к производственной системе.

Как указано в рекомендации, вы должны поэтому определите конфигурацию, относящуюся к вашей инфраструктуре, в файле app/config/parameters.yml.

И наоборот, конфигурация, специфичная для вашего проекта, которая будет статической, будет объявлена ​​в приложение / config / config.yml.

Кроме того, файл параметры.yml не должен быть версионным. Это файл параметры.yml.dist кто должен быть. Именно этот файл даст вам основные параметры для настройки вашего приложения. (рекомендация стр. 12).

В результате файл _приложение / config / config.yml _itself служит рекомендацией.

Установите конфигурацию, связанную с вашим приложением, в app/config/config.yml.
Тем не менее, следуя этой рекомендации, рекомендуется создать файл config.yml, config_dev.yml и файл config_prod.yml. Эти файлы предназначены для хранения констант, характерных для среды разработки и рабочей среды.
Мы должны рассматривать значение как постоянное, когда его значение изменяется очень мало.

Внедрение зависимости

Мы здесь ! В третьей главе подробно изложена рекомендация по использованию зависимостей. Советую прочитать эту рекомендацию, если мое объяснение покажется вам расплывчатым.

Эта рекомендация касается внедрения сервисов в сервисы. Sensio рекомендует объявлять их в файле src/AppBundle/Resources/config/services.yml.

Я также приглашаю вас прочитать мою статью о внедрении зависимостей и о том, как ограничить использование суперсервисного контейнера.

Объявить внутреннюю логику

Глава 4 посвящена организации вашего приложения. В зависимости от ваших потребностей организация будет отличаться. Для глобальных и некоммерческих функций Sensio рекомендует помещать их в папку Utils или просто выньте их из своего пакета и поместите в отдельную папку. После этого настоятельно рекомендуется объявить свой класс сервисом. Новая рекомендация дается, чтобы помочь нам объявить их.

Название вашего сервиса должно быть как можно короче, в идеале одно слово.

Выбор формата файла

Будучи особенно привязанным к формату Yaml в Symfony, я полагаю, что этот момент вызовет разногласия. Sensio бескомпромиссно рекомендует использовать формат Yaml в приложениях. Разработанные пакеты используются в двух форматах: XML и Yaml.

Sensio решил порекомендовать последний просто потому, что он больше " удобно ". Использование другого формата не изменит способ работы вашего приложения.

Не определяйте переменную для объявления ваших услуг

Это практика, которую вы часто увидите в определенных комплектах, и все же Sensio предупреждает вас. Вот пример, приведенный в поваренная книга :

1 2 3 4 5 6 7 8

#app/config/services.yml # оказание услуг defiсоздание с пространством имен класса в качестве параметра параметрами: slugger.class: AppBundleUtilsSlugger услуги: отбивающий: учебный класс: «%слаггер.класс%»

Вот пример бесполезного кода. Объявление класса для службы является ошибкой, поскольку эта переменная может использоваться в другом месте кода. Кроме того, и именно по этой причине Sensio отягощает создание сервиса.

Выбор ОРМ

Sensio рекомендует использовать Doctrine ORM в Symfony. Будучи пользователем Doctrine, его интеграция в Symfony очень продвинута. Это приводит к рекомендации, которая перезапускает логическую организацию наших проектов. Объявление объекта должно содержать логику внутри пакета. См. пример на стр. 18.

Декларация отображения

Декларация отображения Doctrine предпочтительно должна выполняться благодаря аннотациям, которые рекомендуются в рамках Doctrine, а также для других приложений.

Используйте аннотации для объявления сопоставления сущностей.
Пример приведен на странице 19.

Установка светильников

Сенсио советует, не выдвигая вперед, ставить светильники. Для непосвященных: это наборы данных, которые будут использоваться по умолчанию для запуска приложения еще до того, как оно будет запущено в производство.

Стандарты кодирования (конец главы 4)

Это та часть, которую Sensio странным образом почти затмил. Я говорю странно, потому что это важная часть для меня.

Symfony написан с соблюдением стандартов PSR1 и PSR2. Эти стандарты должны продвигаться в сообществе разработчиков Symfony, а также среди разработчиков PHP. Symfony опубликовала статью, чтобы собрать и выделить " Стандарты кодирования ". Лидер Sensio Фабьен Потенсье также разместил на GitHub инструмент для проверки соответствия стандартам.

контроллеры

Когда дело доходит до контроллеров, Symfony philoСофи «тонкие контроллеры и толстые модели». Это означает, что контроллеры должны оставаться легкими. Каждый метод (действие), к которому будет осуществляться доступ через маршрут, представляет собой действие. Код каждого из этих методов должен быть «легким» и вызывать и координировать действия. Эти акции должны быть в сервисах.

Эта модель представляет контроллер как использующий прикладные коды/детали.

Контроллер должен соблюдать несколько правил

• Контроллер должен иметь максимум 5 переменных.
• Контроллер имеет максимум 10 действий.
• Каждое действие должно содержать не более 20 строк.
  • Метод может содержать более 20 строк при условии, что используемый код нельзя факторизовать.
    

    Контроллер должен наследовать базовый контроллер Sensio FrameworkBundle и использовать аннотации для управления маршрутами, кэшированием и безопасностью.

    Рекомендуется использовать аннотации, но допустимо также использование XML, YAML или PHP. Приложение должно использовать только один формат.

Не используйте @Template

Это рекомендация для менее неожиданных, и все же объяснение особенно сильное.

Не используйте аннотацию @Template() для настройки шаблона, используемого контроллером.
Объяснение простое, @Template использует TemplateListener, который вызывается, когда событие ядро.представление бросается.
При подготовке этого документа был проведен тест. Использование @Template занимает 26 мс перед запуском генерации, тогда как для этой же страницы, которая была бы создана с использованием " $this->рендерить(…) », время ожидания 5 миллисекунд.

Использовать аннотацию ParamConverter

Использование этой аннотации позволяет автоматизировать гидратацию объекта.

Использование трюка с ParamConverter хорошо, когда это просто и удобно.

Шаблоны

Глава 6 подробно описывает генерацию шаблона. Это без суеты то, что документ дает нам после нескольких рекомендаций.

• Используйте механизм шаблонов Twig
  Sensio рекомендует Twig по многим причинам. Помимо того, что двигатель широко используется сообществом PHP, как разработчиками PHP с нуля, только разработчиками Symfony и других фреймворков. Подчеркнута простота и хорошо видна реклама их продукта. Наконец, Sensio гарантирует поддержку Symfony вплоть до версии 3. Вы также можете найти первые переходы, которые нужно сделать, чтобы подготовить свой код к переходу на версию 3.
• Храните шаблоны приложений в приложение/Ресурсы/просмотры.
  По умолчанию разработчики привыкли хранить свои шаблоны в папке Полезные ресурсы каждой пачки. Это неплохо, но Фабьен Потенсье рекомендует хранить глобальные шаблоны для вашего приложения в папке, упомянутой выше.
• Определите свои расширения Twig в AppBundle/Twig и настроить службы в приложение/config/services.yml.
  Расширения Twig страдают от плохой видимости. Эти расширения, хотя и очень полезные, иногда используются слишком систематически. Sensio представляет эту часть, которую я считаю важной, как способ внедрения бизнес-кода в свои шаблоны. Я рекомендую вам прочитать, как объявить расширение Twig.

Формы

Глава 7 дает нам инструкции по использованию форм.

• Определите свои формы в классах PHP.
  Symfony дает возможность генерировать классы PHP, позволяющие автоматически генерировать формы для заданных сущностей. НАШИ Формы как они называются, предлагает полную интеграцию. Помогает модификация сущностей. Кроме того, использование Forms позволяет депортировать управление формами из шаблонов.
• Не объявляйте кнопку для отправки ее формы.
  Это удивительный момент, поскольку эта функция была представлена ​​в Symfony 2.5. На момент написания этих строк Symfony 2.6 находился в процессе принятия и, следовательно, еще не был официально выпущен. Поэтому мы можем задать некоторые вопросы о полезности этой функции, ее не следует использовать!Добавляйте кнопки в шаблоны, а не в формы, почему?
  В своем объяснении команда Sensio объясняет, что хотя эта функция остается "удобный" и что это упрощает внедрение форм, некоторые функции остаются ограниченными.
  Например, если вы добавите кнопку типа отправить с меткой «Создать» эту форму нельзя повторно использовать для страницы редактирования. Затем вам нужно будет объявить свою форму как службу для выполнения наследования, что не рекомендуется чуть ниже.
• Не используйте функции Twig форма() и _formНачало().
  Была создана часть, посвященная рендерингу шаблонов. Она учит нас тому, что использование функций Twig форма() И _ форма_старт()_ не рекомендуется. Еще раз, это ошибка для меня, так как эти функции были доступны только недавно.
  В Symfony есть несколько способов рендеринга формы. Из различных способов рендеринга лучшим является тот, который обеспечивает максимальную гибкость.
  Использование перечисленных выше функций Twig приносит мало пользы. Sensio говорит о повышении читабельности при использовании нативных тегов HTML. Несмотря на этот аргумент, это представляет небольшую выгоду… Очень маленькую!

Объявите свои формы сервисами

Формы — это классы PHP, что означает, что они могут быть объявлены как служба. Вы сможете увидеть этот метод в пакетах ДрузьяSymfony. Этот метод не рекомендуется Sensio, за исключением некоторых случаев, которые я привожу ниже:

• Если вы хотите повторно использовать существующие формы. Настройка наследования между двумя формами позволяет ограничить перезапись всех атрибутов.
• Если мы хотим встроить коллекции сущностей.
  Использование форм в качестве сервисов в случае формы добавления или редактирования не рекомендуется, так как использование сервиса загружает @контейнер. Кроме того, будет сложно понять, что этот сервис используется контроллером.

Прикрепите (скрепите) его формы

Недавно Sensio начала постоянную миграцию кода Symfony2 в будущий код Symfony3. Среди перечня модификаций, которые можно сделать (все вы можете найти в UPGRADE-3.md), есть новое решение для связующее вещество запрос, отправленный через форму с форма который был создан. Новая методология подробно описана на странице 21 Лучшие практики.

Озвучить представленный отрывок:

1 2 3 4 5 6 7 8 9 10 11 12 13

что такое варган? функция новое действие(Запрос $ запрос) { // создаем свою форму $form->handleRequest($запрос); if ($form->isSubmitted() && $form->isValid()) { $эм = $ Этой->контейнер->получить(«doctrine.orm.default_entity_manager»); $эм->сохранить($пост); $em->смыть(); возвращение $ Этой-> перенаправить ($ Этой-> сгенерировать URL-адрес («admin_post_show»), массив("идентификатор" => $post->getId())); } }

Интернационализация

Целью модуля интернационализации является перевод контента с одного языка на другой в зависимости от региона или языка пользователя. Эта глава была написана не только для данных рекомендаций, но и для того, чтобы показать возможности этой части, которая всегда остается чувствительной.

В главе 8 редакторы подробно описывают, как активировать перевод.

как насчет формата

Symfony предлагает множество форматов перевода:

• PHP
• Qt
• .по
• .mo
• JSON
• CSV
• ЭТО
• и много других
  

  Используйте формат XLIFF для файлов перевода.
  Эта цитата, очевидно, является рекомендацией Sensio. Да, но почему ? Нам дан краткий и точный ответ.
  Из всех поддерживаемых форматов только формат XLIFF и формат gettext поддерживаются профессиональными инструментами перевода. Поскольку XLIFF основан на XML, он выигрывает от проверки содержимого.
  В Symfony 2.6 появилась новая функция, позволяющая вам «комментировать» (добавлять примечания) в ваши файлы XLIFF. Это большая новинка, потому что генерация файлов перевода может вызвать у переводчиков проблемы с пониманием смысла предложения или контекста, в котором оно используется. Короче говоря, XLIFF хорош!

Где хранить наши файлы переводов?

Этот вопрос вводит Лучшая практика. Sensio рекомендует хранить наши файлы в приложение/Ресурсы/переводы.

Обычно мы хранили наши переводы в каждом из наших пакетов. Это было неплохо, но переводы обычно считаются глобальными частями наших приложений, как и глобальные шаблоны, поэтому Sensio рекомендует хранить их в приложение.

Как перевести наши приложения?

Всегда используйте ключи для перевода контента.
Sur ce Лучшее, свое мнение давать не буду так как у меня мало возможностей переводить приложения. Sensio советует, чтобы перевести такое слово, как «Имя пользователя», вы должны использовать такой ключ, как label.имя пользователя.

Пример приведен на странице 35.

Безопасность

Глава 9 книги касается центральной части Symfony; безопасность !

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

Объявите свои брандмауэры

Параметры конфигурации должны быть введены в файл безопасность.yml который в приложение/конфигурация.

Если у вас нет двух разных подключений к вашему приложению (система и пользователи), мы рекомендуем использовать только один входной брандмауэр с активированной анонимной опцией.
Вау вау вау! Подождите, я приеду на Symfony, я ничего не понял!

Что такое брандмауэр?

Вы можете найти статью, сделанную в Wanadev, о том, как объявить и настроить собственную аутентификацию в Symfony. В этой статье подробно описано, что такое брандмауэр.

Один брандмауэр? Почему ?

Если вы только что прочитали статью по ссылке выше, вы могли заметить, что было объявлено несколько брандмауэров.

В данной статье три имени были DEV, основной et Войти. Несмотря на это, данное правило соблюдается, шлюзом может считаться только межсетевой экран.

• DEV : этот брандмауэр позволяет панель отладки для отображения.
• основной : этот брандмауэр наш ТОЧКА ВХОДА. Анонимные пользователи смогут войти в систему, как если бы они соблюдали правило. Все маршруты, начинающиеся с /, будут использовать эту запись.
• Войти : это файрвол. Это будет наш шлюз в единственном случае: если мы хотим подключиться. Это необходимо для доступа к форме входа.
  Поэтому правило соблюдается.

Определить кодировку

Кодирование паролей является ключевым решением. Существует несколько алгоритмов, таких как ша (sha1, sha256, sha512, md5...).

При объявлении кодировки (см. как объявить кодировку) можно указать три параметра.

• Алгоритм шифрования (по умолчанию: sha512);
• Количество итераций (по умолчанию: 5000);
• Кодировка — base64 закодированного пароля (по умолчанию: true).
  Несмотря на эти значения по умолчанию, которые я предлагаю вам изменить, чтобы изменить их для ваших приложений. Sensio также рекомендует использовать алгоритм Bcrypt.

  Используйте кодировку bcrypt для шифрования паролей пользователей.
  Sensio объясняет, как использовать bcrypt. Это включает в себя засолка ценить. Это ограничивает атаки и более устойчиво к атакам типа грубой силы. Вы можете найти более подробную информацию в статье Википедии выше.

Установить разрешения

Во время соединения Symfony определяет, какой брандмауэр следует использовать. Впоследствии и даже перед доступом к контроллеру выполняется проверка доступа. Они определены в файле безопасность.yml,

Сенсио рекомендует:

1. защищать наши «пограничные шаблоны URL», понимать наши глобальные шаблоны (пример: /admin);
2. Используйте аннотации @Безопасность как можно больше ;
3. Проверить права пользователя через сервис безопасность.контекст (начиная с Symfony 2.6 сервис развился, см. здесь);
4. Определите избирателей, чтобы легко управлять безопасностью дорожного движения;
5. Использовать ACL для управления объектами и правами пользователей.

Используйте аннотации @Security

Sensio рекомендует использовать аннотацию @Security.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

использование SensioПакетFrameworkExtraBundleКонфигурациядорога; использование SensioПакетFrameworkExtraBundleКонфигурацияБезопасность; //… / ** * Отображает форму для создания нового объекта Post. * @Маршрут(«/ новый», имя = «admin_post_new») * @Безопасность("имеет_роль('ROLE_ADMIN')") */ что такое варган? функция новое действие() { //… }

Используйте выражения, чтобы сделать ограничения более сложными

Sensio объясняет нам, что эта аннотация также позволяет генерировать более сложные условия, такие как сравнение двух атрибутов между двумя объектами. Эта аннотация может потребовать использования ПарамКонвертер.

Более подробную информацию вы можете найти в документе:

• Создание выражений
• Преобразование атрибутов в объекты

Безопасность доступа в Twig

Если вы хотите сравнить подключенного пользователя с пользователем объекта, вы можете получить доступ из Twig к пользователь В ходе выполнения.

1 2 3

{% if приложение.пользователь … %} ... {% ENDIF %}

Легко управляйте своей безопасностью

Управление безопасностью часто является важной частью, а организация нашего кода является важной частью успешной защиты нашего приложения. Использование Избирателям настоятельно рекомендуется. Можно рассмотреть и другие способы организации кода. Например, мы можем передать решение методу нашей сущности.

Вы можете просмотреть пример Sensio на странице 40.

Эта часть очень мало детализирована по сравнению с возможностями, которые предлагает Symfony. Советую прочитать еще немного документации по этой части, если вы столкнулись с задачей безопасности.

Веб-активы

Ресурсы позволяют нам управлять такими ресурсами, как Javascript, CSS, шрифты fos, изображения… чтобы они были доступны с ваших страниц.

Ваши активы должны храниться в папке web/
Таким образом, вы можете загрузить свои ресурсы в свои шаблоны следующим образом:

1 2	<ссылке отн="таблица стилей" HREF=« {{ asset(‘css/bootstrap.min.css’) }}«  /> <скрипт SRC=« {{ asset(‘js/jquery.min.js’) }}« ></скрипт>

Сохраните общедоступную веб-папку и все, что в ней хранится.

Использовать актив

Assetic имеет несколько интересов, таких как компиляция файлов. Например, файлы Less, Sass, TypeScript… По этой причине папка Web не может содержать файлы, такие как файлы .меньше.

Используйте Assetic для компиляции, объединения и минимизации ваших активов, если вы не используете GruntJS.

Узнать больше об Ассете

Assetic — полноценный инструмент, несмотря на некоторые недостатки. Вы можете найти документацию по этому модулю, используя ссылки ниже:

• Использовать актив
• Минифицировать CSS и JS
• Сжать изображения
• См. официальную документацию

Настроить тесты

Тестирование признается большинством разработчиков необходимым. Но лишь меньшинство их реализует.

Посмотрим, как Sensio посоветует нам провести наши тесты.

Выполнение модульных тестов

Модульные тесты используются для выполнения функциональных тестов, которые, в свою очередь, проверяют логику вашего приложения. Symfony не определила какие-либо специальные инструменты для проверки ваших тестов. Инструменты PHPUnit et PhpSpec цитируются.

Выполнение функциональных тестов

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

Определите функциональный тест, чтобы проверить, правильно ли загрузилась ваша страница.

Попытайтесь использовать жестко заданные URL-адреса, а не генерировать их с помощью генератора.

Протестируйте функциональность JavaScript

Существует множество инструментов, таких как Норка (библиотека PHPUnit) и КасперДжС.

Создание наборов данных

Это часто беспокоит разработчиков, создающих наборы данных.

Sensio рекомендует использовать библиотеки обманщик et Алиса.

Заключение

Эта статья взята из Лучшие практики для Symfony. Оставаясь простой, эта статья призвана разобрать 50 страниц советов, чтобы помочь новым разработчикам Symfony.