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

Текст из файла (страница 4)

database_host: localhost

database_name: test_project

database_user: root

database_password: password

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

1.9.2 Создание сущностного класса

Предположим, создаётся приложение, в котором необходимо показывать продукты. Чтобы представить эти продукты, необходим объект Product:

class Product {

protected $name;

protected $price;

protected $description;

}

Этот класс – часто называемый «сущность», что значит базовый класс, содержащий данные – помогает выполнять бизнес требования к необходимым продуктам в приложении. Он пока не может храниться в базе данных, так как он всего лишь простой PHP класс.

1.9.3 Добавление информации об отображении

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

Чтобы Doctrine могла сделать это, необходимо создать «метаданные» или конфигурацию, которые в точности расскажут ей как класс Product и его свойства должны быть отображены в базу данных. Эти конфигурации могут быть указаны в большом количестве форматов, включая YAML, XML или прямо внутри класса Product через аннотации. На рисунке 2 представлена конфигурация класса Product с помощью аннотаций.

Рисунок 2

Имена классов и свойств не отображаются в защищённые ключевые слова SQL (такие как group или user). Например, если имя сущностного класса User, тогда, по умолчанию, таблица будет названа user, что вызовет ошибку SQL в некоторых движках.

1.9.4 Создание таблиц

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

php app/console doctrine:schema:update --force

Эта команда сравнивает как должна выглядеть база данных (основываясь на информации об отображении для сущностей) с тем, как она выглядит на самом деле, и создаёт SQL выражения, необходимые для обновления базы данных до того вида, какой она должна быть.

1.9.5 Конструктор запросов Doctrine

Вместо непосредственного написания запросов, можно также использовать Doctrine QueryBuilder (конструктор запросов) чтобы сделать ту же работу, используя объектно-ориентированный интерфейс. На рисунке 3 приведен пример запроса с использованием конструктора запросов Doctrine.

Объект QueryBuilder содержит все необходимые методы для создания запроса. Вызвав метод getQuery(), конструктор запросов вернёт объект Query.

Рисунок 3

1.9.6 Объединение сущностей

Предположим, что все продукты в приложении принадлежат единственной категории. В этом случае, необходим объект Category и способ связывания его с объектом Product. Чтобы связать сущности Category и Product, необходимо создать вспомогательное свойство products в классе Category. На рисунке 4 изображена односторонняя связь сущности Category с Product. Добавленное свойство products будет массивом для хранения объектов Product.

Рисунок 4

Чтобы каждый объект Product мог связываться с одним объектом Category, необходимо добавить свойство $category к классу Product. На рисунке 5 приведен пример отношения таблиц «многие-к-одному».

Рисунок 5

Имеется два класса – Category и Product со связью «один ко многим». Класс Category содержит массив объектов Product и объект Product может содержать один объект Category.

Конфигурация над свойством $category в классе Product сообщает Doctrine, что связанным классом является Category и что он должен хранить id от записи категории в поле category_id, находящемся в таблице product. Другими словами, связанный объект Category будет храниться в свойстве $category, но Doctrine будет хранить эту связь, записывая значение id категории в столбец category_id таблицы product.

2 Реализация серверного функционала сайта

2.1 Цель и этапы разработки

Целью ВКР является разработка серверного функционала сайта с использованием современных инструментов веб-программирования. Разработка функционала сводится к следующим этапам:

– Проектирование схемы базы данных

– Выбор инструментов для решения задачи

– Разработка проекта

2.2 Проектирование схемы базы данных

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

Основным объектом моего будущего будет являться статья. Статья (Article) в целом содержит в себе следующую информацию – заголовок статьи; область науки, к которой принадлежит статья; текст статьи; дата создания. Каждая статья может иметь несколько соавторов. По задумке статьи будут выкладываться в общественный доступ, следовательно, добавим возможность комментирования статьи.

На основе этих соображений сформирована будущая структура базы данных. На рисунке 6 представлена схема базы данных.

Рисунок 6

2.3 Выбор инструментов для решения задачи

Серверный функционал сайта будет описан на языке веб-программирования PHP при помощи фреймворка Symfony. Архитектура проектов Symfony определяется шаблоном проектирования MVC (Модель-Представление-Контроллер).

– Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя свое состояние;

– Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели;

– Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений.

Например, пользователь открывает веб-страницу www.symfony-blog.ru/ (Представление) и нажимает на ссылку «Каталог научных статей». Контроллер реагирует на это действие и сообщает Модели о необходимости сделать выборку всех статей из базы данных. После того как Модель получила запрашиваемые данные, она передает их в Представление. Таким образом, пользователь переходит на другую страницу, где видит каталог всех опубликованных на сайте статей. Концепция MVC архитектуры изображена на рисунке 7.

Рисунок 7

2.4 Разработка проекта

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

Разработка первой страницы на Symfony начинается с конфигурации файла routing.yml и назначения маршрутов. Файл routing.yml сверяет маршрут (path), введенный пользователем в адресную строку браузера с конфигурацией и, в случае совпадения маршрутов, передает управление указанной функции контроллера (default). Функции контроллера называют action-функциями (от слова «действие»).

Для начала следует определить адрес, по которому будет доступна главная страница сайта. Например, меня интересует адрес www.symfony-blog.ru/. Данному маршруту назначим контроллер с методом indexAction. Этому методу будет поставлена простая задача – отобразить шаблон главной страницы веб-сайта. На рисунке 8 содержимое конфигурации routing.yml на текущем этапе.

Рисунок 8

Теперь, когда появилась первая страница проекта, на нее можно помещать ссылки, чтобы реализовать больше возможностей. Основной такой возможностью является просмотр всех статей, опубликованных на сайте. Так как информация о статьях находится в базе данных, необходимо ее получить. Обычно выборки данных производят с помощью языка структурированных запросов SQL. Однако использование реляционной базы данных для хранения информации приводит к семантическому разрыву. Придется писать программное обеспечение, которое должно уметь, как обрабатывать данные в объектно-ориентированном виде, так и уметь сохранить эти данные в реляционной форме. Такие программные обеспечения значительно снижают производительность. К счастью, Symfony поставляется с инструментом, способным предотвратить такие трудности. Технология ORM Doctrine (Объектно-реляционное отображение) облегчит написание объемных запросов и, обладая собственным объектно-ориентированным диалектом SQL, называемым DQL (Doctrine Query Language), раскроет потенциал ООП. Doctrine не только позволяет осуществлять выборки данных, но и предоставляет возможность создания базы данных прямо из проекта.

По замыслу, база данных должна содержать три таблицы: «Articles», «Authors», «Comments». Представим таблицу «Articles», как PHP-класс, а поля таблицы, как объекты данного класса. Взаимодействие с Doctrine происходит с помощью аннотаций, особых комментариев для конфигурации. Любой объект, который необходимо сохранить в базе данных с помощью Doctrine называется Сущностью (Entity). Таким образом, каждую таблицу базы данных необходимо представить в виде сущности Doctrine. На рисунке 9 класс «Article» является примером сущности.

Рисунок 9

Типы и свойства данных также настраиваются с помощью аннотаций. Например, у каждой таблицы есть свой уникальный идентификатор. Он должен быть числом (integer) и его значение должно увеличиваться на один с каждым добавлением новой записи. Сообщим Doctrine об этом. На рисунке 10 изображена сущность «Article», готовая стать таблицей в базе данных. Однако сначала необходимо настроить связи между таблицами. На рисунке 11 изображена связь «один-к-многим» сущностей «Articles» и «Authors». По аналогии настраиваем все сущностные связи. После этого сущности готовы стать таблицами в базе данных. Перед тем, как начать использовать созданную БД, необходимо заполнить ее начальными данными. Это можно сделать как с помощью СУБД, так и средствами Doctrine.

Рисунок 10

Рисунок 11

Все выборки данных производятся в файле Repository (репозиторий, хранилище), который олицетворяет понятие Модуля в архитектуре MVC. Прежде всего, присвоим адресу www.symfony-blog.ru/catalog выполнение функции catalogAction контроллера ArticleController. Внутри контроллера обратимся к Модели (файлу репозитория) и запросим выборку всех имеющихся статей в базе данных. Контроллер запишет полученные данные в переменную articles и, завершая свою работу, передаст эту переменную в Представление (шаблон, макет сайта). Параллельно сделаем запрос на выборку последних трех опубликованных статей. Эта информация будет использована в виджете (информационном окне) в правой части страницы веб-сайта. На рисунке 12 представлено содержимое catalogAction функции контроллера. На рисунке 13 представлен DQL-запрос из файла репозитория в базу данных. Результат только что созданной веб-страницы проекта изображен на рисунке 14.

Характеристики

Список файлов ВКР