3.2. Диаграммы двухуровневой и трехуровневой моделей
Пришло время нарисовать схему взаимодействия частей программы при использовании двухуровневой и трехуровневой модели построения, а также еще раз подчеркнуть их различия. Стрелками (рис. 1 и 2) обозначены зависимости, которые можно охарактеризовать словами как "предоставляет данные". Пунктирные стрелки отмечают зависимости, реализуемые достаточно редко. На схемах это не что иное, как переадресация на другую страницу, возможно, выполняемая генератором данных.
Рис. 1. Двухуровневая схема
Мы видим, что в случае двухуровневой схемы связи между компонентами сценария исключительно циклические (см. рис. 1). Каждая часть программы взаимодействует на равных с другой ее частью.
Рис. 2 гораздо сложнее, чем рис. 30.1. Его "загруженность" объясняется тем, что трехуровневая схема более, чем это может показаться с первого взгляда, сложна и универсальна по сравнению с двухуровневой. Обратите внимание на то, что практически все связи стали двусторонними, а циклические — исчезли. Это позволяет работать блокам более независимо, чем для случая двухуровневой модели. А значит, работу над сценарием можно распределить по нескольким исполнителям более эффективно, — к чему мы и стремились.
Единственный блок программы, который не связан с другими двусторонними связями, — файл конфигурации системы. Это неудивительно, ведь конфигурация содержит лишь набор определений констант и переменных, которыми пользуются все остальные блоки схемы. Впрочем, стрелка, ведущая из блока конфигурации в шаблон страницы, хотя и может существовать без особых последствий, все-таки иногда выглядит несколько нелогично. Рекомендуется так строить сценарии, чтобы шаблону не требовалась информация о конфигурации. Он должен обращаться только к данным, сгенерированным интерфейсом.
Рис. 2. Трехуровневая схема
3.3. Интерфейс
Как можно заметить из листинга 4, интерфейс сценария гостевой книги стал гораздо проще, чем это было с генератором данных из листинга 2. Файл, в котором содержится его код, называется точно так же, как и файл генератора. Это и не удивительно: "снаружи" интерфейс выглядит как полноценный генератор данных, а о существовании ядра шаблон даже и не "подозревает".
Листинг 4. Интерфейс: gbook.php
<?
include "kernel.php"; // Загружаем ядро.
$Book=LoadBook(GBook); // Загрузка гостевой книги.
// Обработка формы, если сценарий запущен через нее.
if(!empty($doAdd)) {
// Добавить в книгу запись пользователя.
$Book=array(time()=>$New)+$Book;
// Записать книгу на диск.
SaveBook(GBook,$Book);
}
// Загрузка шаблона не нужна — теперь, наоборот, шаблон
// вызывает интерфейс.
?>
Как видим, интерфейс занимается только той работой, для которой он и предназначен: выступает "посредником" между ядром и шаблоном. Самым первым загружается ядро — файл kernel.php (я люблю так его называть). Дальше осуществляется исключительно обработка и "расшифровка" входных данных и формирование выходных.
3.4. Ядро
Ядро — это самая ответственная, но, на мой взгляд, в то же время и самая скучная часть работы программиста. Действительно, оно напрямую не взаимодействует с шаблоном страницы, а значит, не имеет права "общаться" с пользователем. Ядро в идеале должно содержать лишь набор функций, которые позволяют исчерпывающим образом работать с объектом программы. В этом смысле идеально его объектно-ориентированное построение.
Листинг 5. Ядро: kernel.php
<?
// Загружаем конфигурацию.
include "config.php";
// Загружает гостевую книгу с диска. Возвращает содержимое книги.
function LoadBook($fname)
{ $f=@fopen("gbook.dat","rb");
if(!$f) return array();
$Book=Unserialize(fread($f,100000));
fclose($f);
return $Book;
}
// Сохраняет данные книги на диске.
function SaveBook($fname,$Book)
{ $f=fopen("gbook.dat","wb");
fwrite($f,Serialize($Book));
fclose($f);
}
?>
Действительно, здесь нет ничего, кроме определений функций и еще одной инструкции include (на этот раз последней). Она добавляет конфигурационные данные нашей книги — всего лишь одну-единственную константу GBook, определяющую имя файла, в котором гостевая книга и будет храниться.
Листинг 6. Конфигурация: config.php
<?
define("GBook","gbook.dat"); // имя файла с данными книги
?>
Что же у нас получилось в результате? Мы "растянули" простой сценарий на целых 5 файлов (если считать еще и .htaccess, то на 6). Тут все дело в том, что для простых сценариев (а именно такой мы и рассматривали) трехуровневая схема построения оказывается чересчур уж "тяжеловесной". Что же касается сложных систем, не следует забывать, что "единственность" ядра может сэкономить нам количество файлов, если у комплекса много различных интерфейсов (например, разветвленная система администрирования), не говоря уже о простоте отладки и поддержки. Кроме того, можно полностью разделить работу по написанию ядра и интерфейса между несколькими людьми.