Основные сведения

Наверное никто не будет оспаривать полезность паттерна Model-View-Controller. Но реализовать его можно по разному. Самый очевидный и, вероятно, самый быстрый — писать на голом PHP, соблюдая определенную самодисциплину. Помещать в скрипт только HTML, подстановку переменных и необходимый минимум "логики представления". Например форматирование данных.

Если страница не совсем уж простая, могут понадобиться проверки. Вариант "есть данные" выводить одним способом, а "нет данных" другим. Это тоже логика представления. Но граница между Контроллером и Представлением неочевидна. В коллективе разработчиков эту границу каждый участник может понимать по-своему. Поэтому будет нелишним провести ее принудительно. И тут может пригодиться обязательное использование шаблонов.

Есть еще аргумент "за". Польза от разделения труда верстальщика и веб-программиста тоже очевидна. Каждый из них может сосредоточиться на эффективности своей работы. Верстальщику незачем знать тонкости PHP и особенности обработки данных в конкретном приложении. Он создает страницу "в статике" и передает ее для применения программисту. Места для подстановки реальных данных он обозначает заранее оговоренным способом. Фактически это шаблон!

Противники шаблонов приводят "железный" аргумент — производительность. Шаблон потребует дополнительных накладных расходов. Можно найти разумный компромис: парсер шаблонов может генерировать текст на PHP. Парсинг выполняется один раз после обновления шаблона, а потом всякий раз работает "родной" код. Представление будет работать настолько быстро, насколько оптимален скомпилированный код.

Зачем создавать новый парсер, если есть готовые?

Затем, что идеала или универсального решения не существует. Для каждой задачи есть свои оптимальные инструменты. Моя цель — реализовать шаблоны со строгим следованием MVC, минималистическим синтаксисом и максимальной производительностью. Я считаю, что избыточные возможности только во вред самой идее MVC. Код библиотеки должен быть небольшим, чтобы его было выгодно вставлять в простые приложения.

Я нахожусь в выгодном положении по сравнению с разработчиками авторитетных библиотек: можно сделать все с нуля не волнуясь об обратной совместимости. Мой шаблон не богат вариантами конструкций, он делает самое необходимое, но делает это быстро (то есть его скомпилированный код не перегружен лишним).

Фактически все накладные расходы сводятся к:

Как это работает

Контроллер готовит данные для Представления в виде единого ассоциативного массива. Вызов отображения — это одна команда:

parseTemplate('путь до файла-шаблона', $array);
А дальше обработчик сам проверит обновлялся ли шаблон или можно сразу подключить готовый PHP-файл. Ни парсер, ни скомпилированный PHP-код не засоряют общее пространство имен, не создают служебных объектов. Им нужен только ваш массив с данными.

Парсер не занимается обработкой ошибок. Вообще! Если что-то не так — об этом сообщит PHP.

Как можно ускориться

Если нужно…

Оптимизация кода. Открою мировой секрет: если вы используете отдельный девелоперский сервер для отладки и отдельный рабочий сервер с реальными нагрузками (надеюсь так и есть), то на рабочем сервере вы можете не использовать шаблоны. Парсер компилирует шаблоны в PHP. Когда работа верстальщика выполнена и все нужные шаблоны проверены, привлеките гуру, который поработает над оптимизацией готовых модулей и уже его результат выкладывайте на рабочий сервер. Скомпилированный код очень прост для понимания.

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

See also