Основные понятия (глоссарий)
-
Точка входа
Все запросы, приходящие на сайт, обрабатываются через файл /index.php который является своего рода распределителем просматривающим по какому адресу пришёл пользователь и отправляющий его к коду непосредственно запрашиваемой страницы (а точнее к контроллеру нужного компонента). Его основной задачей является запуск самого движка до запуска кода запрошенного компонента.
-
Контроллер
По своей сути, контроллеры - это просто php файлы с кодом. Однако важно идеологическое предназначение этого кода. Именно в контроллере определяется как необходимо реагировать на тот или иной запрос т.е. в контроллере мы располагаем частный код для конкретной страницы сайта (конкретного компонента). Хранятся в папке /src
-
Шаблон
Шаблоны - это php файлы с html кодом страницы сайта, или части сайта. Основным предназначением является оформление вывода данных полученных от контроллера (или же просто вывод html, если это статическая страница)
Хранятся в папке /tpl -
Языковой файл
Php файл с текстовыми данными, зависящими от выбранного языка сайта. Такие файлы нужны чтобы не вписывать напрямую текст страниц в шаблоны, а задавать через переменные записанные в данном файле, тем самым сохранив возможность простым подключением другого языкового файла получить страницу на новом языке.
Хранятся в папке /lang/нужный_язык -
Модель
Класс в котором инкапсулирована вся работа с некоторой сущностью БД. Например класс UserModel может содержать в себе методы для работы с mysql таблицей users. Данный механизм позволит меньше обращаться с БД напрямую, а это означает добавит свободы в изменении и дополнении архитектуры работы с данными. Рассмотрим пример работы с пользователем при использованием моделей:
// Так мы можем обновлять поля в БД для пользователя с id 1001 $user = new UserModel(1001); $user->name = "New user name"; $user->email = "example@example.com"; // Или вход пользователя $user = new UserModel(); $user->Login($login, $pwdHash); // Выход пользователя $user = new UserModel(); $user->Logout();
Преимущества такого метода очевидны, спрятав реализацию методов и получения данных, мы сможем изменять их в будущем. Всего лишь несколько примеров улучшений, которые можно осуществить при использовании моделей:
1) Если у пользователя может быть несколько полей email, то на первых порах мы можем сделать поля email1, email2, email3 в таблице user, но данное решение не красивое (временное) и потому в будущем мы можем изменить его, создав отдельную таблицу user_emails для хранения почтовых адресов в ней. Однако в работе наших скриптов ничего менять не придётся и мы сможем просто перехватывать вызов данного поля (метод __get) и делать запрос к user_emails получая нужный адрес. Так же мы сможем перехватывать и запись в это поле (метод __set);
2) В первой реализации мы можем сделать у пользователя поле last_activity, где будем хранить время последнего посещения сайта, обновляя его при авторизации. А в будущем создать таблицу user_activity, где хранить лог о каждом заходе с дополнительной информацией (ip с которого заходили, время и пр.). В модели же, при запросе данного поля, мы сможем перехватывать это событие (метод __get) и делать запрос в таблицу user_activity, просто выбирая последнюю запись;
3) В начале мы можем сделать одну таблицу для всех данных пользователей, а в будущем разбить её на две: для неизменяемых данных и для данных которые могут быть обновлены. Как следствие запретить mysql-пользователю изменять таблицу с неизменными данными (разрешить только insert и select для этой таблицы). Таким образом мы получаем дополнительную защиту от ошибок, котороая находится на более низком уровене по отношению к нашим програмным кодам (уровень запросов к БД).
Все это означает, что модели позволяют не только продумать архитектуру приложения на этапе их написания, но и открывают огромные возможности для оптимизации и масштабирования приложения. -
Компонент
Некоторая независимая часть сайта, например: блок авторизации, страница контактов, меню и т. д. Состоит, как правило, из 3-х основных частей (Языковой файл, Контроллер, Шаблон). Но иметь все 3 составляющие не обязательно.
Компонент включается в нужное место страницы при помощи функции IncludeCom()
Рассмотрим пример:<html> ... <body> <div id="header"> <a href="/">Logo</a> <?php // Включаю компонент block_user_login который // либо покажет формочку для ввода логина и пароля // если юзер не авторизован, либо блок с именем // пользователя и кнопкой "Выход" если авторизован IncludeCom("block_user_login"); ?> </div> ... </body> </html>
В нашем случае, компонент block_user_login будет состоять из 3-х частей: 1) языковой файл - где определены все текста используемые в src и tpl файлах; 2) src-файл в котором написан код определяющий авторизован человек или нет; 3) tpl-файл где выводится либо форма для авторизации, либо приветсвие пользователя. Таким образом мы имеем компонент, который является достаточно обособленной частью сайта.
Стоит так же отметить, что в реальности содержимое компонента может быть значительно больше, а именно:
1) Файл функций: /core/func/любое_имя.php;
2) Файл инициализации: /core/init/любое_имя.php;
3) Файл глобальных языковых переменных, которые автоматом загрузятся во время инициализации движка: /lang/язык/autoload/любое_имя.php;
4) Языковые файлы самого компонента: /lang/язык/название_компонента.php;
5) Контроллер компонента: /src/название_компонента.php;
6) Шаблон компонента: /tpl/название_компонента.php;
7) Файл css оформления: /i/css/любое_имя.css (должен быть подключен в tpl-файле);
8) Javascript файл: /i/js/любое_имя.js (должен быть подключен в tpl-файле).
-
HMVC
HMVC - это архитектурное развитие паттерна MVC с возможностью иерархического вызова триад MVC друг из друга (или как в нашем случае - вызова одного компонента из другого).
Для лучшего понимая, изучите следующую схему работы MVC паттерна и его развития HMVC:
-
Production сервер/режим
Режим работы сайта с серверными настройками и на конфигурации компьютера, аналогичной серверной.
Как пример, в этой конфигурации может быть вывод ошибок в лог-файлы, а не в браузер, подключение к реальным БД, а не к локальным копиям и пр. -
Debug сервер/режим
Режим работы предназначенный для разработки, т.е. режим противоположный Production