Zend Framework
Введение
- это открытый, объектно-ориентированый
фреймворк для PHP 5. Zend Framework часто называют "библиотекой
компонентов" потому что он имеет много слабо связаных компонентов, которые
можно использовать, в большей или меньшей степени, независимо.также предоставляет
расширенную реализацию паттерна Модель-Вид-Контроллер (Model-View-Controller -
MVC), который можно использовать для создания базовой структуры приложения. MVC
своего рода стандарт в проектировании современных веб-приложений, так как
большая часть кода веб-приложений подпадает под одну из трех категорий:
представление, бизнес логику или доступ к данным. Паттерн MVC хорошо моделирует
разделение этих понятий. В результате, код представления, бизнес логики и
доступа к данным разделен и сгруппирован в разных частях приложения. Четко
определенное разделение необходимо для поддержания кода организованным,
особенно при командной разработке.
Рисунок 1 - Общий вид MVC
Model - Модель, это часть приложения, которая определяет
его основную функциональность как множество абстракций. В модели можно
определить процедуры доступа к данным и бизнес логику.- Вид, определяет, какое
представление имеет информация, передаваемая пользователю. Обычно, контроллеры
передают данные виду для отображения их в каком-либо формате. Кроме того, вид
часто получает данные от пользователя. Это та часть паттерна, в которой,
вероятнее всего, находится HTML разметка вашего MVC приложения.- Контроллеры
связывают весь паттерн в единое целое. Они управляют моделями, на основе
пользовательского ввода и других факторов решают какой из видов отобразить,
передают виду необходимые данные, или полностью передают управление другому
контроллеру.имеет следующие особенности:
Все компоненты написаны на полностью
объектно-ориентированном коде PHP 5 и E_STRICT совместимы
Архитектура "слабого
связывания" с минимальными зависимостями между частями проекта(Use-at-will
<#"871112.files/image002.jpg">
Рисунок 2
На рисунке показано движение запроса в типичном
приложении ZendFramework.
Поскольку перед контроллером ставится задача
перехвата запросов клиента и направления их подходящему целевому объекту для
формирования ответа, front- контроллер играет ключевую роль в движении запроса
через приложение.
.Когда приходит запрос, файл .htaccess
веб-сервера автоматически приводит его к стандартному формату и передает
сценарию index.php. Этот сценарий подготавливает окружение приложения, читает
его конфигурационный файл и создает экземпляр front-контроллера.
.Front-контроллер анализирует запрос и
определяет основные компоненты URL. Затем он направляет запрос подходящему
контроллеру. Для выполнения этой маршрутизации front-контроллер проверяет как
стандартные, так и пользовательские маршруты и задействует методы сопоставления
по шаблону для выбора цели запроса.
.Если найдено совпадение, front-контроллер
передает управление соответствующему контроллеру. Будучи вызванным, действие вносит
изменения в состояние приложения, используя одну или несколько моделей. Оно
также выбирает отображаемое представление и устанавливает в нем необходимые
параметры. После завершения действия выбранное представление формирует страницу
с его выводом, в случае необходимости помещая вывод в макет. После чего этот
вывод возвращается клиенту
.Если ни один из определенных в приложении
маршрутов не совпадает с запросом, выбрасывается исключение и вызываются
контроллер и действие, предназначенные для обработки ошибки. В зависимости от
параметров исключения действие формирует представление, содержащее сообщение об
ошибке. Затем этот вывод возвращается клиенту
Как говорилось ранее, подсистема маршрутизации
автоматически сопоставляет URL в формате /модуль/контроллер/действие
соответствующим модулю, контроллеру и действию. Например, для доступа к
действию ListingController :: SaveAction в модуле auto вам необходимо будет
запросить URL #"871112.files/image003.jpg">
Рисунок 3 - Форма, созданная с
помощью стандартной HTML-разметки
Хотя приведенный сценарий и весь
подход в целом работают на практике, невозможно отрицать тот факт, что у них
сущствует ряд проблем:
.Один и тот же файл сценария
содержит как элементы интерфейса, описанные на HTML, так и бизнес-логику на
РНР. Как говорилось в предыдущей главе, такое соседство не только неряшливо
выглядит, но и осложняет сопровождение. Помимо этого, становится сложнее
поддерживать согласованность форм, так как код, необходимый для создания каждой
из них, может подвергаться существенной модификации.
.Каждый раз, когда в первой половине
сценария вы добавляете на форму новое поле, вам также необходимо добавить
соответствующий набор проверок и сообщений об ошибках в его вторую половину.
Это надоедающее и часто повторяющееся действие; взять хотя бы тот факт, что две
первые проверки из предыдущего примера делают, в сущности, одно и то же.
.Не существует способа повторно
использовать проверочные тесты из одной формы в других формах (если только вы с
самого начала предусмотрительно не упаковали их в классы или функции). В
результате вам часто приходится писать один и тот же код снова и снова,
особенно при работе с формами, осуществляющими взаимосвязанные или схожие
действия.
В состав Zend Framework входит набор
компонентов с общим названием Zend_ Form, которые решают перечисленные
проблемы. В целях демонстрации рассмотрим следующий пример, где Zend_Form
используется, чтобы создать сценарий, эквивалентный предыдущему:
<?phpForm_Item_Create
extends Zend_Form {function init()
{
// инициализируем форму
$this->setAction('/item/create')
>setMethod(‘post’);
// создаем текстовое поле для ввода имени
Sname = new Zend_Form_Element_Text(‘name’):
$name->setLabel(‘Item
name:’)
>setOptions(array(‘size’
=> ‘35’))
>setRequired(true)
>addValidator(‘NotEmpty’.
true)
>addValidator(‘Alpha’.
true)
>addFilter(‘HtmlEntities’)
>addFilter(.‘StringTrim’);
// создаем текстовое поле для ввода количества
$qty = new Zend__Form_Element_Text(‘qty’):
$qty->setLabel(‘Item
quantity:’):
'$qty->setOptions(array(‘size’
=> ‘4’))
>setRequired(true)
*
->addValidator(‘NotEmpty’. true)
>addValidator(‘Int’.
true)
>addFilter(‘HtmlEntities’)
->addFi1 ter(‘StringTrim’);
// создаем кнопку для отправки
^submit =
new Zend Form Element Submit(‘submit’);
$submit->setLabel('Submit')
>setOptions(array('class'
=> 'submit')):
// добавляем к форме элементы
$thi s->addElement($name)
>addElement($qty)
>addE1ement($submi
t):
}
}ExampleControl1er
extends Zend_Controller_Action {function formActionO
{= new
Form_Item_Create;
$this->view->form
= Sform; if (Sthis->getRequest()->isPostO) { if
(Sform->isValid($this->getRequest()->getPost())) {=
$form->getValues();
$pdo = new
PD0(‘mysql;dbname=test;host=localhost'. ‘user’, ‘pass’); $sql =
sprintf("INSERT INTO shoppinglist (name, qty)
VALUES
(‘£s\ ‘£d’)\ $values[‘name’]. $values[‘qty’]); $pdo->exec($sql);
$thi
s->_helper->getHelper(‘FIashMessenger')
>addMessage(‘Спасибо');
$this->_redirect(‘/index/success’);
}
}
}
На рисунке 3 показана форма,
созданная с использованием компонента Zend.Form.
Рисунок 4 - Форма, созданная с
использованием компонента Zend.Form
В коде, создающем приведенную на
рис. 3.2 форму, вы наверняка заметили три особенности:
.В сценарии нет ни одной строчки
HTML-кода. Форма и ее элементы представлены в виде объектов РНР и настраиваются
с помощью методов этих объектов. Такой подход обеспечивает согласованность и
создает веб-форму, соответствующую стандартам.
.Для распространенных задач
валидации и очистки ввода доступны встроенные валидаторы и фильтры. Они
уменьшают количество выполняемой работы, помогают создавать более простой в
сопровождении код и избегать повторений. Кроме того, для соответствия
нестандартным требованиям валидаторы можно комбинировать и расширять.
.Валидаторы указываются одновременно
с полями формы. Это позволяет форме «знать», какие данные поддерживаются каждым
полем, и легко определять источник ошибок ввода. Для более строгой валидации
одному полю можно назначить несколько валидаторов.
Отсюда вытекает, что Zend_Form
предоставляет удобное, простое в сопровождении и расширяемое решение для
создания форм ввода и валидации данных.
Глава 3. Работа с моделями в
ZendFramework
Введенные на форме данные не растворяются в
пустоте; они должны куда-то попадать. Обычно под «куда-то» подразумевается база
данных, например MySQL, SQLite или PostgreSQL, поэтому добавление поддержки
базы данных в приложение становится основной задачей разработчика.
3.1 Модели
Модели представляют слой данных, ответственный
как за предоставление канала, через который можно получить доступ к данным, так
и за поддержание и соблюдение любых бизнес-правил связанных с этими данными.
Например, при создании системы учета книг для онлайн-библиотеки вы можете
использовать модель Transaction, которая будет не только записывать информацию
о взятых и возвращенных книгах, но и содержать правила, запрещающие читателю
иметь на руках более пяти книг единовременно или автоматически рассчитывающие
плату за просроченный возврат и списывающие ее со счета соответствующего
пользователя. Аналогично, при создании приложения для продажи авиабилетов вы
можете использовать модель Ticket, которая будет не только сохранять и получать
записи о приобретении билетов, но и автоматически увеличивать или уменьшать
стоимость билета в зависимости от загруженности конкретного рейса.
Пример простой модели:
<?php
// модель для обработки данных о клиентах class
MemberModel {
protected
$db;Sid;Sname;Sage;Stype;Srate;
// конструктор
// инициализируем подключение к базе данных
public function_construct()
{>db = new
PD0('mysql;dbname=db;host=localhost', 'user',
’pass');>db->setAttribute(PDO::ATTR_ERRMODE, PDO;:ERRMODE_EXCEPTION);
}
// получаем запись о клиенте по его
идентификатору
public function fetch(Sid)
{=
$this->db->quote(Sthis->id);= Sthis->db->query("SELECT *
FROM member WHERE id = Sid");$rs->fetchAll(PDO::FETCH_ASSOC);
}
// получаем записи обо всех клиентахfunction
fetchAll()
{
$rs = $this->db->query(’SELECT
* FROM member");$rs->fetchAll(PDO::FETCH_ASSOC);
}
// добавляем новую запись о клиентеfunction
save()
// фильтруем входные данные
{
$f = array();
$f['name'] =
htmlentities($this->name):
$f['age'] =
htmlentities($this->age);
$f['type'] =
htmlentities($this->type):
// проверяем
возраст($f['age']
< 18) { throw new Exception('Member under 18);
}
// автоматически вычисляем скидку в зависимости
от статуса клиента
switch ($fС
* type']) {'silver';
$f['rate'] = 0; break;'gold';
$f['rate'] = 0.10; break;'platinum';
$f['rate'] = 0.25; break;
}
$this->db->exec(
'INSERT INTO member (Name, Age.
Type. DiscountRate) VALUESC . $this->db->quote($f['name']) . '. '
$this->db->quote($f['age']) .
'. '
$this->db->quote($f['type']) . '.
'
$this->db->quote($f['rate']) .
')'
):$this->db->lastlnsertld();
}
}
?>
Как видно, для взаимодействия с базой данных
MySQL эта модель использует абстракции РНР - PDO. Она предоставляет несколько
методов для полудня записей из базы данных и сохранения их в базу. В ней также
содержатся некоторые бизнес-правила (автоматический подсчет скидки, основанный
на статусе клиента) и некоторые правила валидации ввода (проверка того, что
клиент не моложе 18 лет). Как и у всех хороших моделей, ее начальной и конечной
целью являются данные; модель не содержит сведений о том, как эти данные
форматируются и отображаются.
Пример возможного использования этой модели в
приложении:
<?phpSandbox_ExampleController
extends Zend_Controller_Action {function saveActionO
{($this->getRequest()->isPost()) { if
($form->isValid($this->getRequest()->getPost())) {
$model = new MemberModel;
$model->name =
$form->getValue('name’);
$model->age =
$form->getValue('age');
$model->type =
$form->getValue('type'):= $model->save();
$this->view->message =
"Record saved with ID: Sid";
}
}
}
}
директория фреймворк паттерн
3.2 Паттерны для моделей
Для работы с моделями существуют два часто
используемых паттерна: DataMapper и ActiveRecord. В предыдущем примере
продемонстрирован паттерн ActiveRecord, в котором класс модели непосредственно
соответствует таблице в базе данных и предоставляет для работы с записями этой
таблицы такие методы, как save(), update() и delete(). Очевидно, что в этом
паттерне модели и соответствующие им таблицы базы данных тесно связаны друг с
другом, и внесение изменений в одну из них требует внесения изменений в другую.
Паттерн DataMapper несколько отличается от
ActiveRecord, так как не требует наличия отношения 1:1 между классом модели и
соответствующей таблицей базы данных. Вместо этого в нем используется
промежуточный слой (mapper - от отображающий класс), с помощью которого
решается задача отображения данных из класса модели на поля таблицы. В этом
случае именно отображающий класс предоставляет методы save(), update() и
fetch() и осуществляет преобразования» необходимые для корректного отображения
элементов класса на поля в базах данных. Данный паттерн обладает большей
гибкостью и большим разнообразием возможных конфигураций, нежели ActiveRecord;
кроме этого, отделение данных от их хранилища приводит к созданию более удобных
для восприятия простых сопровождений моделей. Однако реализовать паттерн
DataMapper сложнее чем ActiveRecord.
Как правильно выбрать паттерн? Простого ответа
на этот вопрос не существует потому что он равносилен вопросу о том, какой сорт
мороженого лучше. Паттерн ActiveRecord, по определению, предполагает, что для
хранения данных вы используете базу данных, а модели, основанные на этом
паттерне, тесно связаны с ее структурой. Такой сценарий подойдет для маленьких
проектов или для проектов, в которых основная функциональность по большей части
соответствует стандартному набору команд SELECT, INSERT, UPDATE и DELETE.
Паттерн DataMapper позволяет явно разделить бизнес-правила уровня приложения и
хранилище данных, и именно сама модель, а не лежащая в основе база данных,
используется для определения данных. Как следствие, вы не ограничены только
лишь базой данных; класс отображения может столь же легко отображать данные на
другие типы хранилищ, такие как обычные файлы, XML или LDAP. Этот паттерн
подойдет для проектов со сложными структурами данных и/или пользовательскими
форматами для их хранения или же для проектов, основная функциональность
которых требует более сложных взаимодействий между сущностями приложения.
3.3 Границы модели
Зачастую сложно провести черту между тем, что
должно находиться в модели, и тем, что должно находиться в контроллере.
Например, для описанного ранее примера с банковскими операциями можно
утверждать, что валидация, относящаяся к суммам и местоположениям, должна
осуществляться в контроллере, а не в модели. Однако в целом сообщество
разработчиков приняло подход «толстая модель, тонкий контроллер»,
рекомендованный различными программистами, включая Мартина Фоулера (Martin
Fowler), Джеймиса Бака (Jamis Buck) и Криса Хартджеса (Chris Hartjes). Этот
подход предлагает по возможности размещать бизнес-логику в моделях, а не в
контроллерах, и обладает рядом преимуществ:
.Инкапсулируя ключевые бизнес-правила в объектах
и методах объектов, пригодных для многократного использования, «толстые» модели
уменьшают дублирование и помогают разработчикам придерживаться принципа «Не
повторяй самого себя» (Don’t Repeat Yourself, DRY). Впоследствии для
согласованного применения этих правил в приложении можно использовать цепочки
наследования. Кроме того, определение моделей с использованием принципов ООП
дает возможность наращивать функциональность базовых моделей по мере
необходимости, а также разграничивать открытые и закрытые атрибуты моделей в
более крупных приложениях.
.Самодостаточные «толстые» модели,
инкапсулирующие все бизнес-правила, необходимые для их корректной работы,
являются более переносимыми, чем «тонкие» модели, которые полагаются на то, что
за соблюдение бизнес-правил будут отвечать контроллеры приложения. Поскольку
основная часть бизнес- логики приложения находится в модели, а не в
контроллере, упрощается, например, переход на другой фреймворк, так как можно
просто переместить модель в новую систему, и она будет работать как обычно, не
требуя существенной Модификации.
.Когда большая часть тяжелой работы выполняется
«толстыми» моделями, Контроллеры обычно содержат лишь несколько строк
узкоспециализированного кода. Это упрощает их чтение и понимание, а также
повышает общую производительность (поскольку контроллеры обычно вызываются
чаще, чем модели). Помимо этого, упрощается сопровождение кода: например, если
вам потребуется изменить бизнес-правила для определенной сущности в приложении,
необходимо будет обновить только модель для этой сущности, а не все
контроллеры, которые ее используют.
.При подходе «толстая модель, тонкий контроллер»
отладка и тестирование становятся более прозрачными, потому что обычно очень
легко определить, является ли источником ошибки модель или же контроллер, и
исправить эту ошибку, оказав минимальное влияние на остальную часть приложения.
Важно отметить, что в состав Zend Framework не
входит компонент Zend_Model или набор стандартных моделей, которые вы могли бы
«присоединить» к своему приложению: придется создавать собственные модели. Zend
Framework включает в себя несколько инструментов, способных помочь в решении
этой задачи: например, слой абстракции баз данных Zend_Db_Adapter и интерфейс
для операций с таблицами Zend_Db_Table.
Заключение
В отличии от других языков программирования PHP
не навязывает общий стандарт написания кода. В результате стиль кода в
различных приложениях на PHP существенно различается у разных разработчиков,
что затрудняет поддержание согласованности проекта. Относительный недостаток
строгости в PHP приводит к появлению некачественного кода, что делает его
уязвимым. ZendFramework ,напротив, объединяет в себе приёмы программирования,
считающимся лучшим на сегодняшний день, представляет стандартную схему
размещения фалов в файловой системе и обеспечивает встроенную поддержку для
решения распространённых задач, возникающих при разработке приложений, таких
как валидация и очистка входных данных. Следовательно, использование этого
фреймворка как основы для создания проекта на PHP автоматически приводит к
созданию более качественного кода и приложения, более устойчивого к проблемам
безопасности.