- •2.2. Изоляция представления.
- •2.3. Изоляция логики Приложения (Домена)
- •2.4. Изоляция разметки (Layout)
- •2.5. Добавляем страницу блога “show”¶
- •2.6. Front Controller
- •2.7. Создание фронт-контроллера
- •2.8. Прикосновение к Symfony2
- •2.9. Простое приложение на Symfony2
- •2.10. Преимущество Symfony2
- •2.11. Лучшие шаблоны
ЛАБОРАТОРНАЯ РАБОТА 2
СОЗДАНИЕ ПРОСТЕЙШЕГО ПРОЕКТА С ИСПОЛЬЗОВАНИЕМ ФРЕЙМВОРКА SYMFONY
Почему использовать Symfony2 лучше, чем простой PHP файл, который можно просто открыть и писать код, не задумываясь?
В данной лабораторной работе Вы создадите простенькое приложение на чистом PHP и выполните его оптимизацию. Вы увидите, как Symfony2 поможет Вам избавиться от рутинных задач и получить контроль над кодом.
2.1 Простой блог на чистом PHP¶
Создадим простое приложение – блог, используя лишь обычный PHP. Чтобы начать, создайте страницу, которая отображает записи в блоге, которые были сохранены в базе данных:
<?php
// index.php
$link = mysql_connect('localhost', 'myuser', 'mypassword');
mysql_select_db('blog_db', $link);
$result = mysql_query('SELECT id, title FROM post', $link);
?>
<html>
<head>
<title>List of Posts</title>
</head>
<body>
<h1>List of Posts</h1>
<ul>
<?php while ($row = mysql_fetch_assoc($result)): ?>
<li>
<a href="/show.php?id=<?php echo $row['id'] ?>">
<?php echo $row['title'] ?>
</a>
</li>
<?php endwhile; ?>
</ul>
</body>
</html>
<?php
mysql_close($link);
Такой код быстро пишется, также быстро выполняется, но, по мере роста вашего приложения, становится совершенно неподдерживаемым. Таким образом, тут имеется несколько проблем, которые требуется решить:
Нет обработчика ошибок.
Плохая организация кода: по мере роста приложения этот файл будет все больше и больше, в то же время поддерживать его будет всё сложнее и сложнее. Возникают вопросы. Где разместить код, который обрабатывает отправку формы? Как проверять входные данные? Куда поместить код для отправки электронных адресов?
Сложность (а скорее даже невозможность) повторного использования кода: так как весь код располагается в одном файле, нет никакой возможности повторного использования любой части приложения для других страниц блога.
Другая проблема, не упомянутая выше, заключается в том, что Вы фактически привязаны к базе данных MySQL. Symfony2 изначально интегрирована с ORM Doctrine, библиотекой, отвечающей за абстракцию от баз данных и соответствие данных между СУБД и Вашими сущностями (mapping).
Решим поставленные выше проблемы.
2.2. Изоляция представления.
При отделении “логики” приложения от кода, который подготавливает HTML “представление” страницы, общая структура приложения сразу же выигрывает:
<?php
// index.php
$link = mysql_connect('localhost', 'myuser', 'mypassword');
mysql_select_db('blog_db', $link);
$result = mysql_query('SELECT id, title FROM post', $link);
$posts = array();
while ($row = mysql_fetch_assoc($result)) {
$posts[] = $row;
}
mysql_close($link);
// include the HTML presentation code
require 'templates/list.php';
HTML код теперь расположен в отдельном файле (templates/list.php), который главным образом представляет собой HTML-файл, который использует PHP-синтаксис “для шаблонов”:
<html>
<head>
<title>List of Posts</title>
</head>
<body>
<h1>List of Posts</h1>
<ul>
<?php foreach ($posts as $post): ?>
<li>
<a href="/read?id=<?php echo $post['id'] ?>">
<?php echo $post['title'] ?>
</a>
</li>
<?php endforeach; ?>
</ul>
</body>
</html>
По договорённости файл, который содержит всю логику приложения - index.php – называется “контроллер”. Термин controller – это слово, которое Вы будете частенько слышать вне зависимости от языка программирования или же фреймворка, который используете. В действительности же, речь идёт о части вашего кода, который обрабатывает пользовательский ввод и готовит ответ.
В нашем случае контроллер получает данные из базы и подключает шаблон для того, чтобы отобразить их. С изоляцией контроллера Вы получили возможность поменять лишь шаблон, если Вам вдруг понадобится отобразить записи блога в другом формате (например list.json.php для использования JSON-формата).
2.3. Изоляция логики Приложения (Домена)
Пока наше приложение содержало всего одну страницу. Но что же делать, если нужно добавить вторую страницу, которая использует то же подключение к базе данных или даже тот же массив постов из блога? Преобразуем код, изолировав базовую логику от функций доступа к БД - поместим их в новый файл под названием model.php:
<?php
// model.php
function open_database_connection()
{
$link = mysql_connect('localhost', 'myuser', 'mypassword');
mysql_select_db('blog_db', $link);
return $link;
}
function close_database_connection($link)
{
mysql_close($link);
}
function get_all_posts()
{
$link = open_database_connection();
$result = mysql_query('SELECT id, title FROM post', $link);
$posts = array();
while ($row = mysql_fetch_assoc($result)) {
$posts[] = $row;
}
close_database_connection($link);
return $posts;
}
Имя файла model.php использовано не случайно - логика и доступ к данным приложения традиционно известен как уровень “модели”. В правильно организованном приложении бОльшая часть кода, представляющая собой “бизнес-логику”, должна быть расположена в модели (в противовес расположению её в контроллере). И, в отличие от нашего примера, лишь часть модели отвечает за доступ к БД (а бывает и вообще не отвечает).
Контроллер (index.php) теперь выглядит очень просто:
<?php
require_once 'model.php';
$posts = get_all_posts();
require 'templates/list.php';
Теперь в обязанности контроллера входит получение данных из модели приложения и вызов шаблона для отображения данных. Это очень простой пример паттерна model-view-controller.