Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное учреждение

высшего образования

«Тульский государственный педагогический университет им. Л.Н. Толстого»

Кафедра информатики и информационных технологий

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

(БАКАЛАВРСКАЯ РАБОТА)

на тему:

проектирование и разработка веб-приложения на основе технологий symfony framework

Выполнена: студентом группы 120831

очной формы обучения

факультета математики, физики и

информатики

Фуксом Дмитрием Евгеньевичем

Тула - 2017

Работа выполнена на факультете математики, физики и информатики ФГБОУ ВО «ТГПУ им. Л.Н. Толстого»

Научный руководитель - Ваныкина Галина Владиславовна, кандидат педагогических наук, доцент кафедры информатики и информационных технологий.

Работа допущена к защите:

Заведующий кафедрой информатики и информационных технологий.

___________________ ______________________ А. В. Якушин

Защита состоится «____» __________ 20____ г. в учебном корпусе №____ ТГПУ им. Л.Н. Толстого, ауд. № _____в______ часов.

Декан факультета математики, физики и информатики

___________________ _________________________ И. Ю. Реброва



ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ТЕХНОЛОГИЙ SYMFONY FRAMEWORK

1.1 История развития веб-технологий и существующие проблемы

1.2 Обзор типовых решений в области веб-разработки

1.3 Модель MVC и ООП в веб-программировании

1.4 Назначение и установка Symfony Framework

1.5 Структура Symfony Framework

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

1.5.2 Бандлы

1.5.3 Сущности Doctrine

1.5.4 Маршрутизация

1.5.5 Контроллеры

1.5.6 Шаблонизатор Twig

1.5.7 Генерация форм и валидация

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

1.5.9 Сервисы

1.5.10 Консольные команды

1.5.11 Механизмы тестирования

1.6. Развертывание приложения Symfony

ГЛАВА 2. СОЗДАНИЕ ПРИЛОЖЕНИЯ НА ОСНОВЕ ТЕХНОЛОГИЙ SYMFONY FRAMEWORK

2.1 Постановка задачи

2.2 Настройка develop-сервера и установка Symfony

2.3 Установка дополнительных библиотек через composer

2.4 Вёрстка шаблона, npm, webpack

2.5 Генерация сущностей и форм

2.6 Определение маршрутов и контроллеров

2.7 Создание и настройка сервисов

2.8 Написание консольных команд и заданий cron

2.9 Тестирование

2.10 Перенос проекта на production-сервер

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЯ

Приложение A. Конфигурационные файлы

Приложение B. Класс сущности Game

Приложение C. Репозиторий GameRepository сущности Game

Приложение D. Класс генерации формы на основе сущности

Приложение E. Маршруты и контроллер публичной части сайта

Приложение F. Сервис для работы с корзиной и заказами. Настройка сервисов

Приложение F. Класс консольной команды очистки заброшенных корзин

Приложение G. Функциональный тест виджета добавления в корзину и конфигурация PHPUnit



ВВЕДЕНИЕ

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

Актуальность выпускной квалификационной работы определена неразрешёнными проблемами в области веб:

· возрастание нагрузки на сервер;

· уязвимость приложений;

· обеспечение масштабируемости приложения;

· необходимость версионирования кода;

· стандартизация кода;

· обеспечение администрирования и поддержки приложения.

Цель выпускной квалификационной работы - выполнить анализ возможностей технологий Symfony Framework и реализовать приложение интернет-магазина компьютерных игр на основе современных подходов в области веб-разработки. Для достижения поставленной цели были определены следующие задачи:

· провести анализ современных типовых технологий и моделей в области веб;

· выполнить анализ возможностей Symfony Framework в области веб;

· выполнить проектирование и реализацию веб-приложения на базе Symfony Framework;

· выполнить тестирование функционала приложения.

Практическую значимость выпускной квалификационной работы можно охарактеризовать как адаптацию оригинальной документации Symfony Framework на русский язык и разработку веб-приложения на основе современного ООП-подхода.

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

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ТЕХНОЛОГИЙ SYMFONY FRAMEWORK

1.1 История развития веб-технологий и существующие проблемы

В 1991 году британский учёный, изобретатель Тим Бернерс-Ли создал первую веб-страницу. Несмотря на то, что интернет, как таковой существовал ещё с 60-х годов 20-го века, именно появление WWW (Всемирной паутины) послужило огромным толчком для развития веб-технологий и появления взаимодействия пользователя с веб-браузером [1].

На ранних этапах развития веб-технологий исходный код веб-страницы представлял собой простой набор html-тегов, а для просмотра таких страниц существовал единственный браузер «WorldWideWeb», позже переименованный в «Nexus». С 1994г. по 1996г. произошло несколько важных событий:

* Создание консорциума Всемирной паутины (1994г.)

* Выпуск браузеров Netscape Navigator (1994г.) и Internet Explorer (1995г.)

* Появление языка программирования PHP (1995г.)

* Появление языка программирования JavaScript (1995г.)

* Появление языка разметки CSS (1996г.)

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

В период с 2000г. по настоящее время в сети возникло огромное количество социальных сетей, поисковиков, развлекательных сервисов, интернет-магазинов и т. д.

По состоянию на 15 марта 2017-го всемирная паутина насчитывает свыше 1150млн. сайтов, а также 3500млн. Интернет-пользователей [2].

В связи с огромной популярностью веб-приложений ужесточились требования к возможностям функционала, дизайну, отказоустойчивости, безопасности и т. д. В области веб на данный момент существует ряд проблем, обусловленные различными факторами [3]:

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

* Небезопасность. Веб-приложения подвергаются хакерским атакам с целью заполучения конфиденциальных данных. Необходимо защищать сервер от различных видов атак. От простого перебора пароля до масштабных DDOS-атак.

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

* Использование единых стандартов и подходов при написании кода. Данная проблема неразрывно связана с проблемой, указанной выше. При разработке проекта несколькими программистами или при передаче его другим лицам необходимо обеспечить его удобочитаемость, возможность легко дополнять и изменять, код должен соответствовать общеизвестным стандартам, а архитектура приложения должна быть построена на общепринятых подходах.

* Выбор оптимальных для решения конкретной задачи языков программирования, разметки, IDE, системы управления базами данных, шаблонизаторов и т. д. Для каждого конкретного проекта оптимальными являются различные технологии. Необходимо учитывать его масштабность, область применения, планируемые нагрузки, квалификацию разработчиков и т. д. И с учётом всех факторов выбирать именно те, или иные средства разработки.

* Оптимизация кода с целью получения наилучшего быстродействия. Не только удобочитаемость кода и использование единых подходов должны учитываться при написании кода. Необходимо его постоянная оптимизация (отказ от запросов к БД в цикле, минификация стилей и скриптов, создания механизма кеширования и т. д.)

* Обеспечение поддержки проекта. После переноса проекта на «боевой сервер» могут появляться некоторые баги, некорректное отображение данных, необходимость расширения функционала и т. д. Поэтому даже после полной готовности и выполнения всех задач по проекту необходимо обеспечивать его поддержку.

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

* Использование сторонних библиотек и зависимостей. При разработке проекта часто появляются задачи, которые уже были реализованы в той, или иной степени сторонними разработчиками и оформленными ими в виде библиотек (компонентов, модулей). Необходимо обеспечивать возможность использование таких библиотек и удобное подключение их в разрабатываемому проекту.

* Тестирование. Данная проблема связана с проблемой обеспечения поддержки проекта. Чем больше кода было покрыто тестами, тем меньше непредвиденных багов возникнет в процессе функционирования приложения.

* Создание хоста разработки. Так как любое веб-приложение разрабатывается для работы на сервере, в процессе разработки у программиста должна иметься возможность работы с сервером, который в некоторый степени эмулирует работу «боевого» хоста. Таковым может являться локальный хост, виртуальная машина, удалённый хост.

* Написание документации, технического задания, общение с заказчиком. Любое приложения разрабатывается «для кого-то», даже если программист пишет его сам для себя. В связи с этим вместе с приложением должна поставляться удобная документация и периодическая консультация заказчика по работе с приложением.

* Проектирование и создание удобного и интуитивно-понятного пользовательского интерфейса. Так как в конечном счёте с любым веб-приложением будет взаимодействовать пользователь, необходимо обеспечить для него удобное и простое взаимодействие с приложением.

1.2 Обзор типовых решений в области веб-разработки

· Операционная система Ubuntu 16.04 (рис. 1)

Является одной из самых популярных операционных систем семейства Linux. Выпускается в редакции Server и Desktop. Обладает предустановленным сервером Apache2, PHP7.0, mysql и ещё целым рядом программ, предназначенных для веб-разработки. Все популярные инструменты и технологии как правило создаются конкретно для пользователей данной операционной системы.

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

Для максимально удобного использования Ubuntu необходимы знания консольных команд, в которой происходит большинство взаимодействий с системой. Нет необходимости постоянного использования браузера и поиска нужных программ, скачивания их, настройки и т.д. Все эти действия заменят ввод пары команд в консоли.

Система является защищенной к вирусным атакам, обладает встроенными инструментами шифрования, распространяется бесплатно, обладает большим сообществом, регулярно обновляется [4].

Рис. 1. Рабочий стол Ubuntu 16.04

· Язык программирования PHP 7

Является намного быстрее по сравнению со своим предшественником PHP5.6 согласно источнику html5.by (рис. 2)

Рис. 2. Тест производительности PHP7 при работе различных фреймворков

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

· Язык программирования ECMAScript 6

Одним из самых важных нововведений в последних версиях ECMAScript является полноценная поддержка использования классов, несмотря на то, что они, по сути, являются синтаксическим сахаром (конструкцией языка для упрощения реализации программного кода) прототипами [5].

Из остальных значительных нововведений можно выделить поддержку импорта и экспорта модулей, строковые шаблоны, введение нового способа объявления переменных через let и const, а также появление стрелочных функций.

· Менеджер пакетов Composer

Composer - это пакетный менеджер для языка PHP. Он упрощает установку каких-либо сторонних библиотек, используемых в проекте, перенос проекта от одного разработчику к другому.

Работа с composer осуществляется через командную строку. При установке какого-либо пакета, располагающегося в репозитории, имеется возможность указания версии. Composer обладает встроенным автозагрузчиком классов, прост в установке и конфигурации [6].

· Менеджер пакетов NPM

NPM представляет собой менеджер пакетов, входящий в состав NodeJS. Имеет огромную базу приложений в репозитории, упрощают установку и интеграцию различных js, css и прочих библиотек [7]. Так же, как и с Composer, взаимодействие осуществляется через командную строку, но имеется и возможность использования графических оболочек. Содержимое конфигурационного файл представляет собой json-массив, аналогично таковому в Composer.

· Шаблонизатор Twig

Twig является шаблонизатором, написанным на языке PHP. Позволяет жёстко разграничить понятия Controller и Viewer, так как при написании шаблона страницы используется только характерные для Viewer функции и синтаксис, который в свою очередь является более удобным и сокращённым по сравнению с PHP [8].

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

У Twig открытый исходный код, имеется русскоязычная документация.

· ORM Doctrine

Doctrine создаёт слой абстракций над БД и позволяет связать их с концепциями объектно-ориентированного программирования. Работа с базой данных представляет собой исключительно взаимодействие с объектами. Каждая таблица - объект [9].

Doctrine избавляет программиста от написания дублирующегося кода в виде однотипных SQL-запросов, а синтаксис взаимодействия с объектами абсолютно не зависит от выбранной СУБД, обладает системой защиты от SQL-инъекций, обеспечивает сохранение целостности данных, имеет обширную документацию. При необходимости изменения СУБД код переписывать не нужно.

· Система контроля версий Git

Git является системой контроля версий, обладает как и возможностью консольного управления, так и графической оболочкой, интегрирован во множество IDE, имеет высокую производительность [10].

· IDE PhpStorm

PhpStorm идеально подходит для работы с Symfony, Drupal, WordPress, Zend Framework, Laravel, Magento, Joomla!, CakePHP, Yii, и другими фреймворками. Он индексирует весь код проекта, поддерживает множество языков, автодополнение, рефакторинг кода, подсветку ошибок, встроенные инструменты для работы с SFTP, консолью, базами данных и т. д. [11].

Для студентов PhpStorm распространяется бесплатно.

· Инструмент для сборки фронтенда Webpack

Инструмент для сборки фронтенда, обеспечивающиый объединение различных модулей, минимизацию файлов, использование различных загрузчиков и преобразователей. Обладает гибкими настройками, автоматической пересборкой при изменении, проектирование в зависимости от окружения [12].

· CSS-фреймворк Material Design Lite

Позволяет использовать элементы Material Design на сайте. Данный фреймворк не связан ни с каким js-фреймворком и является универсальным. Страницы, разработанные с помощью MDL будет придерживаться современных принципов веб-дизайна, поддерживать мобильные браузеры, будут адаптивны и минималистичны.

MDL включает в себя новые версии управления пользовательским интерфейсом, такие как кнопки, флажки и текстовые поля. Библиотека также включает в себя расширенные и специализированные функции, такие как карты, макеты колонок, ползунки, счетчики, вкладки и многое другое [13].

· Язык стилей LESS

Язык существенно расширяет стандартные возможности CSS, добавляет возможность использования переменных, вложенности, примесей, функций, операций. Любой валидный CSS код является валидным и в LESS [14].

· PHP-фреймворк Symfony3 (рис. 3)

Один из самых популярных и современных PHP-фреймворков на данный момент. Он использует модель MVC, поддерживает множество различных баз данных, в составе фреймворка поставляется Doctrine, Twig, Composer, а также ряд других библиотек. Весь исходный код фреймворка соответствует стандартам PSR, имеет поддержку PHP7. Symfony имеет собственный хост разработки, подробную документацию по функционалу с подробными примерами. Обновления появляются регулярно с периодичностью в несколько недель [15].

Рис. 3. Панель статистики в Symfony3

· БД PostgreSQL

Является объектно-реляционной базой данных, то есть содержит технологии, реализующие объектно-ориентированный подход [16]. Некоторые преимущества PostgreSQL по сравнению с MySQL:

o Подзапросы можно писать отдельно, давая им имена.

o Большое количество различных типов данных, в том числе возможность добавления пользовательских типов.

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

o Тип json и полноценная работа с ним.

o Хранимые процедуры на любых языках.

o Репликация работает быстро и консистентно.

o При правильной настройке запросы выполняются в разы быстрее.

o Строгий режим. В отличии от MySQL, PostrgreSQL не позволит сделать двусмысленный запрос и получить обрезанную строку, случайное число и т. д.

o Полнотекстовый поиск.

o Последовательности. В MySQL есть только AUTO_INCREMENT на поле таблицы, с итерацией по одному. В PostgreSQL этот механизм живет отдельно от таблицы, что можно использовать для самых разных потребностей, кроме того можно их создавать зацикленными.

1.3 Модель MVC и ООП в веб-программировании

веб разработка библиотека контроллер

MVC (Model, View, Controller) - шаблон проектирования проектов. Он был разработан задолго до появления WWW, но широкое распространение получил именно в веб-разработке. Адаптировавшись под потребности разработчиков, и став основой многочисленному количеству фреймворков, данный шаблон стал очень популярным и востребованным среди веб-разработчиков [17].

Основной идеей MVC является чёткое разделение функционирования приложения (рис. 4).



Рис. 4. Компоненты MVC

Контроллеры обрабатывают запросы от пользователя, будь то обычный GET-запрос, отправка формы, AJAX-запрос и т. д. При получении каких-либо данных, например, параметр в url, задача контроллера - вызвать модель, если необходимо отправить определённые данные от пользователя в методы модели, получить результат и вернуть его на вывод (отобразить вид) в требуемом формате (JSON, HTML, XML и т. д.) Как правило, внутри контроллера не должно быть кода, связанного с непосредственной работой с БД, сложных вычислений, обработки данных и т. д. Распространённой ошибкой разработчиков является то, что бизнес-логика описывается внутри контроллеров, а на модель возлагается только работа с базой данных, из-за чего объём кода контроллеров сильно засоряется и становится сложно читаемым. А так же нарушается основная идея MVC - разделение функциональности. Единственная задача контроллера - получить данные от пользователя, отправить в модель, получить результат и отправить его на вывод.

Модель реализует логику работы приложения - описание сущностей, конфигурацию приложения, подключение к БД, выборки, валидацию, механизмы защиты данных, взаимодействие с внешними сервисами, обработка ошибок и т. д. Основная задача модели - сформировать данные для отправки их в контроллер, а также работа с полученными данными, т. е. реализация бизнес-логики приложения.

Вид получает данные от контроллера и выводит их пользователю в необходимом формате. Как правило таковым является HTML-код, который отображается браузером, но также это может быть JSON-массив (в ответ на AJAX-запрос), сформированный PDF, XML, DOC и т. д. Единственная задача вида - отобрать данные.

В связи со спецификой модели MVC, а именно - чёткого разделения функционирования приложения, при разработке приложений, в том числе в основе многих фреймворков, используется объектно-ориентированное программирование [18]. Основой данного подхода служит единая точка входа, как правило файл index.php (зависит от настроек сервера и файла .htaccess), расположенный в корне сайта, и определённый внутри него автозагрузчик классов. Любой запрос к сайту должен быть перенаправлен именно к этому файлу.

<?

function __autoload($className)

{

$className = ltrim($className, '\\');

$fileName = '';

if ($lastNamespacePos = strrpos($className, '\\')) {

$namespace = substr($className, 0, $lastNsPos);

$className = substr($className, $ lastNamespacePos + 1);

$fileName = str_replace('\\', '/', $namespace) . '/';

}

$fileName = $_SERVER['DOCUMENT_ROOT'].'/'.strtolower($fileName).$className.'.php';

if (file_exists($fileName)) {

require_once($fileName);

} else {

die('Класс ' . $className . ' не найден');

}

}

Листинг 1. Пример простейшего автозагрузчика классов

При вызове в любом участке кода какого-либо класса функция __autoload, указанная в листинге 1, пытается подключить файл с соответствующим именем с учётом пространства имён. В случае отсутствия такового выполнение скрипта прекращается. Это обеспечивает подключение только необходимых в процессе выполнения скрипта файлов.

Следующей неотъемлемой частью данного подхода является роутер. Он обрабатывает входную url-строку и определяет какой метод класса-контроллера должен быть вызван. В общем случае каждой url-строке ставится в соответствие определённый метод класса-контроллера. В случае, если соответствие не установлено, отображается страница 404.

Класс-контроллер представляет собой набор методов, задача которых получить входные данные, обработать их с помощью методов классов-моделей и возвратить ответ, который будет выведен пользователю. В приложении таковых классов может быть множество, они могут наследоваться от базового абстрактного класса-контроллера, содержать вспомогательные методы, которые не вызываются роутером. Но основная их задача, в соответствии с MVC - содержать методы, которые получают входные данные от пользователя и возвращают ему результат обработки.

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

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

1.4 Назначение и установка Symfony Framework

Использование фреймворков позволяет структурировать разработку, повторно использовать общие модули, облегчает долгосрочное обслуживание и масштабируемость в соответствии со стандартными правилами разработки. По сравнению с CMS, фреймворки обеспечивают гибкость и могут быть использованы для разработки приложений, которые наиболее точно соответствуют заявленным требованиям, но в тоже время требуют определённые технические знания, связанные с разработкой, интеграцией и техническим обслуживанием [19].

По сравнению с самописными приложениями, использование фреймворков гарантирует соответствие кода современным стандартам, структурирование, поддержку и масштабируемость. А также сокращает время разработки, позволяет повторно использовать модули [20].

Symfony Framework - свободный PHP-фреймворк, разработанный компанией Sensio Labs в соответствии с паттерном MVC и предназначенный для создания сайтов и веб-приложений. Он простроен на основе компонентов Symfony, каждый из которых может быть использован отдельно от самого фреймворка. Первый релиз состоялся 22 октября 2005 года. Последней версией является 3.3.2 (6 июня 2017 года), требует PHP 5.5.9 и выше, поддерживает большое количество баз данных (PostgrerSQL, MySQL, SQLite) благодаря ORM-инструменту Doctrine. Одна из самых популярных CMS - Drupal 8 основа на Symfony Framework [21].

Symfony предоставляет специальное приложение под названием Symfony Installer для упрощения создания приложений Symfony. Этот установщик представляет собой исполняемый файл, совместимый с PHP 5.4, который должен быть установлен в системе только один раз:

#Linux и MacOS

sudo mkdir -p /usr/local/bin

sudo curl -LsS https://symfony.com/installer -o /usr/local/bin/symfony

sudo chmod a+x /usr/local/bin/symfony

#Widnows

php -r "readfile('https://symfony.com/installer');" > symfony

Листинг 2. Команды для установки Symfony Installer

После установки Symfony Installer для создания приложения Symfony необходимо ввести команду «symfony new project_name».

Эта команда создает новый каталог, project_name/ который содержит пустой проект, основанный на последней версии стабильной версии Symfony. Кроме того, установщик проверяет, соответствует ли система техническим требованиям для выполнения приложений Symfony. Если нет, отобразится список изменений, необходимых для удовлетворения этих требований.

Также имеется возможность создавать приложения Symfony с помощью Composer, менеджера зависимостей, используемого современными PHP-приложениями. Для этого используется команда «composer create-project symfony/framework-standard-edition project_name». Для обновления компонентов Symfony используется команда «php bin/console server:run».

Symfony использует внутренний веб-сервер PHP (доступный с PHP 5.4) для запуска приложений при их разработке. Запуск приложения Symfony осуществляется командой «php bin/console server:run». После этого необходимо перейти в браузере по адресу http://localhost:8000/. Если установка прошла успешно, и система удовлетворяет требованием отобразится страница приветствия (рис. 5).

Рис. 5. Страница приветствия Symfony 2.8.0

1.5 Структура Symfony Framework

В последующих подпунктах будет произведён анализ технологий Symfony Framework на основе официальной документации [15].

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

Каждое приложение Symfony состоит из набора бандлов (пакетов), которые добавляют инструменты (севрисы) в проект. Каждый бандл может быть настроен через файлы конфигурации, которые по умолчанию расположены в каталоге app/config (см. листинг 3).

imports:

- { resource: parameters.yml }

- { resource: security.yml }

- { resource: services.yml }

framework:

secret: '%secret%'

router: { resource: '%kernel.project_dir%/app/config/routing.yml' }

# ...

# Twig Configuration

twig:

debug: '%kernel.debug%'

strict_variables: '%kernel.debug%'

Листинг 3. Главный файл конфигурации config.yml

Любой файл конфигурации может быть описан с помощью файлов в формате YAML, XML и PHP. По умолчанию используется YAML, так является наиболее простым, чистым и читаемым. XML более мощный, чем YAML, и поддерживает автодополнение IDE. PHP наиболее мощный, но менее читаемый, чем стандартные форматы конфигурации.

Для того, чтобы использовать какие параметры можно настроить необходимо использовать справочный раздел, либо команду «php bin/console config:dump-reference название_библиотеки». Для импорта настроек используется специальный ключ imports, который работает аналогичного include в PHP. Другой специальный ключ называется parameters: он используется для определения переменных, на которые можно ссылаться в другом файле конфигурации. Чтобы ссылаться на параметр, необходимо окружить его название двумя знаками процента. Параметры, которые являются уникальными для каждого сервера, например, учетные данные базы данных, должны быть описаны в файле paramentrs.yml, а данный файл исключен из версионного контроля. Но данные параметры могут быть описаны в файле paramentrs.yml.dist в виде фиктивных значений (шаблонов). При разворачивании проекта через composer Symfony предложит ввести фактические значения данных параметров.

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

1.5.2 Бандлы

Бандл похож на плагин в различных ПО. Главное отличие заключается в том, что все бандлы в Symfony, включая базовые компоненты фреймворка, написаны для конкретного пользователя. Бандлы - основа Symfony. Они предоставляют гибкость в использовании предварительно встроенных функций, упакованных в сторонние пакеты или для распространения собственных пакетов. Это позволяет легко выбирать, какие функции включить в приложении, и оптимизировать их с учётом собственных потребностей.

Пакет представляет собой просто структурированный набор файлов в каталоге, реализующем одну функцию. Каждый каталог содержит все, что связано с этой функцией, включая файлы PHP, шаблоны, таблицы стилей, файлы JavaScript, тесты и все остальное. Каждый аспект функции существует в бандле, и каждая функция расположена в бандле.

Бандлы, используемые в приложениях, должны быть включены путем регистрации их в методе registerBundles() класса AppKernel в файле app/AppKernel.php. Таким образом можно контролировать, какие бандлы необходимо использовать в проекте, а какие нет. Для вызова классов используется автозагрузчик, поставляемый вместе с composer.

Для создания нового бандла необходимо создать директорию src/Имя_разработчика/Название_бандлаBundle, а в ней класс с именем Имя_разработчикаНазвание_бандлаBundle и унаследоваться от базового класса Symfony\Component\HttpKernel\Bundle\Bundle. Далее зарегистрировать созданный бандл в классе AppKernel. В качестве альтернативы можно использовать консольную команду php bin/console generate:bundle --namespace=Имя_разработчика/Название_бандлаBundle. Данная команда генерирует базовый контроллер, шаблон и ресурс маршрутизации.

Каждый бандл обладает следующе структурой каталогов:

· Controller/

Содержит контроллеры бандла.

· DependencyInjection/

Содержит определенные классы расширения Dependency Injection, которые могут импортировать конфигурацию сервисов, описывать собственные сервисы и т. д. (этот каталог не обязателен).

· Resources/config/

Конфигурация бандла, включая конфигурацию маршрутизации (например routing.yml).

· Resources/views/

Содержит шаблоны, организованные по имени контроллера (например, Random/index.html.twig).

· Resources/public/

Содержит веб-ресурсы (изображения, таблицы стилей и т. д.), которые будут скопированы или символически связаны в с web/ каталогом проекта с помощью команды assets:install в консоли.

· Tests/

Содержит все тесты для бандла.

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

Установка стороннего бандла происходит в три этапа:

1. Поиск названия бандла на сайте http://packagist.org и установить его через composer, например, «composer require friendsofsymfony/user-bundle». Эта команда установит последнюю версию бандла, добавит ей в файл composer.json и загрузит в каталог vendor/ проекта.

2. Регистрация бандла в классе AppKernel. В зависимости от специфики бандла, можно зарегистрировать его только для определённой среды разработки.

3. Настройка бандла. Для получения списка доступных параметров конфигурации используется команда «php bin/console config:dump-reference НазваниеБандла». После можно переопределить необходимые параметры в файле app/config/config.yml.

Удаление бандла - более сложный процесс по сравнению с его установкой и происходит в четыре этапа:

1. Удалить регистрацию бандла из класса AppKernel.

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

3. Удалить каталог бандла из директории src/, удалить таблицы стилей, скрипты, картинки из директории web/.

4. Если удаляемый бандл связан с другими, необходимо удалить и все связанные бандлы, так как они не смогут функционировать без удалённой зависимости.

1.5.3 Сущности Doctrine

Одной из наиболее распространенных и сложных задач для любого приложения является сохранение и чтение информации в базу данных и из нее. Symfony Framework не интегрирует какой-либо компонент для работы с базами данных, но обеспечивает тесную интеграцию с сторонней библиотекой под названием Doctrine. Единственная цель Doctrine - предоставить мощные инструменты для легкого и гибкого взаимодействия с базами данных. Он сопоставляет объекты с реляционной базой данных (например, MySQL, PostgreSQL или Microsoft SQL). Также имеется возможность сохранения данных в NoSQL базе данных MongoDB с помощью Doctrine ODM library.

Далее в этом подпункте будет приведён пример создания конкретной базы данных под названием test_project и объекта Product.

Информация о подключении к базе данных описывается в файле конфигурации parameters.yml в виде переменных параметров, которые будут использованы в главном файле конфигурации.

# app/config/config.yml

doctrine:

dbal:

driver: pdo_mysql

host: '%database_host%'

dbname: '%database_name%'

user: '%database_user%'

password: '%database_password%'

Листинг 4. Параметры подключения к базе данных

После настроек подключения Doctrine имеет возможность подключиться к базе данных. С помощью команды «php bin/console doctrine:database:create» Doctrine автоматически сгенерирует пустую базу данных. При использовании SQLite в качестве базы данных, необходимо указать путь, в котором должен храниться файл базы данных. Для этого используется параметр doctrine.dbal.path.

Следующим этапом является создание сущности, а именно класса, расположенного в папке Entity внутри каталога бандла. Данный класс может быть сгенерирован автоматически, с помощью команды «php bin/console doctrine:generate:entity». Данная команда задаёт интерактивные вопросы, которые помогают создать разработчику любой объект.

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



Рис. 6. Пример сопоставления таблицы БД с PHP-объектом

Эта информация представляется в виде «метаданных», набора правил, который сообщает Doctrine, как именно класс и его свойства должны быть сопоставлены с конкретной таблицей базы данных. Эти метаданные могут быть указаны в нескольких разных форматах, включая YAML, XML или непосредственно внутри класса с помощью DocBlock аннотаций. Разработчик имеет возможность выбрать наиболее удобный способ определения метаданных, но наиболее распространённым вариантом является использование аннотаций. Бандл может принимать только один формат определения метаданных. Например, невозможно сопоставить определения метаданных YAML с аннотированными определениями сущностей PHP. Имя таблицы является необязательным и, если оно опущено, будет определяться автоматически на основе имени класса сущности.

<?

namespace AppBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

/**

* @ORM\Entity

* @ORM\Table(name="product")

*/

class Product

{

/**

* @ORM\Column(type="integer")

* @ORM\Id

* @ORM\GeneratedValue(strategy="AUTO")

*/

private $id;

/**

* @ORM\Column(type="string", length=100)

*/

private $name;

/**

* @ORM\Column(type="decimal", scale=2)

*/

private $price;

/**

* @ORM\Column(type="text")

*/

private $description;

}

Листинг 5. Пример ORM-сущности Doctrine с описанием в виде аннотаций

После создания сущностей необходимо проверить её описание с помощью команды «php bin/console doctrine:schema:validate».

Не смотря на то, что Doctrine имеет представление о том, как сохранить объект в базе данных, класс приведённый в листинге 5 является бесполезным. Поскольку Product - это обычный PHP-класс со private свойствами, необходимо создать public методы getter и setter (например getName(), setName($name)), чтобы получить доступ к его свойствам в остальном коде приложения. Команда «php bin/console doctrine:generate:entities AppBundle/Entity/Product» может автоматически генерировать эти шаблонные методы. Эта команда гарантирует, что все геттеры и сеттеры будут созданы для класса. Это безопасная команда - имеется возможность запускать её неограниченное количество раз: она генерирует только геттеры и сеттеры, которые не существуют (т. е. не заменяют существующие методы). Генератор сущности Doctrine создает простые геттеры/сеттеры. При необходимости можно добавить любую логику в соответствии с потребностями создаваемого приложения.

Для автоматического создания всех таблиц базы данных, необходимых для каждого известного объекта используется команда «php bin/console doctrine:schema:update -force». Эта команда сравнивает, как должна выглядеть база данных (на основе информации о сопоставлении сущностей) с тем, как она выглядит на самом деле, и выполняет инструкции SQL, необходимые для обновления схемы базы данных. Другими словами, если добавить новое свойство с метаданными сопоставления в класс сущности и запустить эту команду, она выполнит инструкцию «ALTER TABLE», необходимую для добавления этого нового столбца в существующую таблицу.

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

Независимо от того, используются ли возможности миграции, команда «doctrine:schema:update» должна использоваться только во время разработки. Она не должна использоваться в производственной среде.

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

<?

// src/AppBundle/Controller/DefaultController.php

use AppBundle\Entity\Product;

use Symfony\Component\HttpFoundation\Response;

use Doctrine\ORM\EntityManagerInterface;

use Doctrine\Common\Persistence\ManagerRegistry;

public function createAction(EntityManagerInterface $em)

{

// создание нового объекта класса Product

$product = new Product();

// устанавливает значения свойств

$product->setName('Keyboard');

$product->setPrice(19.99);

$product->setDescription('Ergonomic and stylish!');

// сообщение Doctrine, о намерении сохранить объект

$em->persist($product);

// фактическое выполнение запроса INSERT

$em->flush();

// возвращение ответа

return new Response('Saved new product with id '.$product->getId());

}

Листинг 6. Сохранение объекта в базу данных

Метод flush() использует механизмы кэширования и подготавливает единый запрос к базе в независимости от количества создаваемых объектов.

Для получения объекта из базы данных используются механизмы, аналогичные тем, что указаны в листинге 7.

<?

use Doctrine\ORM\EntityManagerInterface;

public function showAction($productId, EntityManagerInterface $em)

{

// получение репозитория объекта и запрос сущности по её ID

$product = $em->getRepository('AppBundle:Product')

->find($productId);

// вывод сообщения об ошибке в случае отсутствия сущности с указанным ID

if (!$product) {

throw $this->createNotFoundException(

'No product found for id '.$productId

);

}

}

Листинг 7. Получение сущности из базы данных

Для запроса объектов из базы можно использовать различные методы репозитория. Таковыми могут быть как стандартные методы (findBy, find, findAll, findOneBy и т. д.), так и методы, которые определены в репозитории сущности самим разработчиком.

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

Если количество запросов к базе данных слишком велико, значок станет желтым, указывая на то, что что-то может быть неверным. При нажатии на значок, можно открыть Symfony Profiler и посмотреть конкретные запросы, которые были выполнены.

После получения объекта, имеется возможность его обновить, как это указано в листинге 8.

<?

use Doctrine\ORM\EntityManagerInterface;

public function updateAction($productId, EntityManagerInterface $em)

{

// получение репозитория объекта и запрос сущности по её ID

$product = $em->getRepository('AppBundle:Product')->find($productId);

// вывод сообщения об ошибке в случае отсутствия сущности с указанным ID

if (!$product) {

throw $this->createNotFoundException(

'No product found for id '.$productId

);

}

// установка нового значения свойства

$product->setName('New product name!');

// фактическое выполнение запроса INSERT

$em->flush();

// перенапрваление на главную страницу

return $this->redirectToRoute('homepage');

}

Листинг 8. Обновление объекта в базе данных

Для удаления объекта используются метод $em->remove(). Для фактического удаления используется метод $em->flush();

В случае необходимости использования более сложных запросов используется DQL - родной язык Doctrine. Он очень схож с языком SQL, за одним большим отличием - при построении запросов необходимо думать с точки зрения выбора объектов PHP, а не строк в базе данных. Такие запросы можно создавать непосредственно внутри методов классов контроллеров, но для организации Doctrine предоставляются специальные классы репозитория, которые позволяют хранить всю логику запросов в одном централизованном месте.

<?

$query = $em->createQuery(

'SELECT p

FROM AppBundle:Product p

WHERE p.price > :price

ORDER BY p.price ASC'

)->setParameter('price', 19.99);

$products = $query->getResult();

Листинг 9. Пример построения запроса на языке DQL

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

1.5.4 Маршрутизация

Наличие человекопонятных URL-адресов (ЧПУ) является абсолютной необходимостью для любого серьезного веб-приложения. Например, index.php?article_id=57 проигрывает по сравнению с /read/intro-to-symfony.

Маршрутизатор Symfony позволяет определять URL-адреса, которые могут быть сопоставлены с различными областями приложения. Маршрут представляет собой карту из URL пути к контроллеру. Маршруты, как и обычные файлы конфигурации могут быть описаны с помощью аннотаций, YAML, XML или PHP.

# app/config/routing.yml

blog_list:

path: /blog

defaults: { _controller: AppBundle:Blog:list }

blog_show:

path: /blog/{slug}

defaults: { _controller: AppBundle:Blog:show }

Листинг 10. Пример определения маршрутов в формате YAML

При создании маршрутов имеется возможность определения параметров, передаваемых в URL, задавать значения по умолчанию для этих параметров, производить их валидацию по регулярному выражению, указывать допустимые типы запросов к контроллеру ($_GET, $_POST), сопоставлять метод контроллера, устанавливать языковые стандарты по запросу. Имя маршрута не может начинаться с цифры, а также быть длиннее 32 символов.

Symfony загружает все маршруты для приложения из одного файла конфигурации маршрутизации: app/config/routing.yml. Но изнутри этого файла можно загружать любые другие файлы маршрутизации. Фактически, по умолчанию Symfony загружает конфигурацию маршрута аннотаций из каталога бандла Controller/, при использовании YAML, XML, PHP из каталога Recourses/config.

1.5.5 Контроллеры

Контроллер - это созданная функция PHP, которая считывает информацию из Request объекта Symfony и создает и возвращает Response объект. Ответ может быть HTML-страницей, JSON, XML, файлом, перенаправлением, ошибкой 404 или чем-либо еще. Контроллер выполняет произвольную логику, необходимую приложению для отображения содержимого страницы. Он может считывать информацию из запроса, загружать ресурс базы данных, отправлять электронную почту или задавать информацию на сеансе пользователя. Но во всех случаях контроллер в конечном итоге возвращает Response объект, который будет доставлен обратно клиенту.

Для удобства Symfony поставляется с двумя дополнительными базовыми Controller и AbstractController классами. Это позволяет расширить или получить доступ к нескольким вспомогательным методам. Разница между Controller и AbstractController в том, что при расширении AbstractController нет возможности получить доступ к сервисам напрямую через $this->get() или $this->container->get().

Базовый класс содержит следующие методы для удобного определения метода контроллера:

· Перенаправление - return $this->redirectToRoute('homepage');

· Рендер шаблона - return $this->render(index.html.twig', array('name' => $name));

· Получение сервисов в качестве аргументов контроллера. Symfony поставляется с большим количеством полезных объектов, называемых сервисы. Они используются для создания шаблонов, отправки электронных писем, запросов к базе данных и любой другой «работы». Для получения нужного сервиса в контроллере, необходимо указать в качестве аргумента метода контроллера переменную нужного класса или интерфейса. Для получения полного списка доступных сервисов используется команда «php bin/console debug:container -types».

· Доступ к контейнеру - $mailer = $this->get('mailer');

· Отображение ошибки 404. throw $this->createNotFoundException('The product does not exist');

· Управление сессиями - $session->set('foo', 'bar');

· Flash-сообщения - $this->addFlash('notice', 'Your changes were saved!');

· Возвращение JSON-объектов - return $this->json(array('username' => 'jane.doe'));

· Возвращение файлов - return $this->file('/path/to/some_file.pdf');

· Объект Request в качестве аргумента контроллера. Используется для получения данных из массивов $_POST, $_GET, а также значений определённых в маршрутизации параметров.

Request класс имеет несколько открытых свойств и методов, которые возвращают любую необходимую информацию о запросе.

Как и объект Request, Response объект также имеет публичное свойство headers. Он имеет методы для получения и настройки заголовков ответов. Имена заголовков нормализуются так, что использование Content-Type эквивалентно content-type или даже content_type.

Единственное требование для контроллера - вернуть Response объект. Response класс является абстракцией вокруг ответа HTTP - текстовое сообщение, заполненное заголовками и содержанием, которое отправляется обратно клиенту.

1.5.6 Шаблонизатор Twig

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

На самом деле контроллер делегирует большую часть тяжелой работы в другие места, чтобы код можно было тестировать и повторно использовать. Когда контроллер должен сгенерировать HTML, CSS или любой другой контент, он передает работу в механизм шаблонов. Шаблон - это простой текстовый файл, который может генерировать любой текстовый формат (HTML, XML, CSV, LaTeX и т. д.) Наиболее знакомым типом шаблона является PHP-шаблон - текстовый файл, обработанный PHP, который содержит сочетание текста и кода PHP. Но Symfony предлагает собственный язык шаблонов под названием Twig. Twig позволяет писать сжатые, читаемые шаблоны, которые более дружелюбны к веб-дизайнерам и, в некоторых аспектах, более мощные, чем шаблоны PHP.

Twig определяет три типа специального синтаксиса:

{{ ... }}

«Вывести что-то»: печатает переменную или результат выражения в шаблоне.

{% ... %}

«Сделать что-то»: тег, который управляет логикой шаблона; Он используется для выполнения таких операторов, как, например, for-loops.

{# ... #}

«Комментировать что-то»: это эквивалент /* comment */синтаксиса PHP. Он используется для добавления одиночных или многострочных комментариев. Содержание комментариев не включено в отображаемые страницы.

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

Код Twig похож на PHP-код, с небольшими отличиями. В листинге 11 используется стандартный тег for и функция cycle() для печати десять div тегов, с чередованием значений «odd» и «even».

{% for i in 1..10 %}

<div class="{{ cycle(['even', 'odd'], i) }}">

{# some HTML here #}

</div>

{% endfor %}

Листинг 11. Пример синтаксиса шаблонизатора Twig

Шаблоны Twig должны быть простыми и не будут обрабатывать теги PHP. Система шаблонов Twig предназначена для отображения вида, а не программной логики.

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

Twig обладает высоким быстродействием, так как каждый шаблон автоматически компилируется в собственный PHP-класс и кэшируется. Во время разработки Twig повторно компилирует шаблоны после внесения каких-либо изменений.

Чаще всего шаблоны в проекте имеют общие элементы, такие как верхний колонтитул, нижний колонтитул, боковая панель и т. д. В Symfony эта проблема рассматривается по-разному: шаблон может быть интегрирован с другим. Это работает точно так же, как и классы PHP: наследование шаблонов позволяет создать базовый шаблон «макета», содержащий все общие элементы сайта, определенные как блоки с помощью тега {% block name%}text{% endblock%} («PHP-класс с базовыми методами»). Дочерний шаблон может расширять базовый макет с помощью тега {% extends %} и переопределять любые его блоки («дочерний класс PHP, который переопределяет определенные методы его родительского класса»).