В последнее время очень много говорится о схеме проектирования
MVC, почти все популярные PHP-фреймворки уже давно перешли на эту схему. Что же касается
Kohana, то начиная с версии 3, реализована иерархическая схема MVC –
HMVC. Преимущества HMVC, всем понятны и мы не будем их здесь обсуждать.
Я, как желающий сменить статус «программиста-любителя» на «программиста-профессионала» решил, что уже достаточно изучил PHP и пора начинать работать с фреймворками, выбор моего самого первого фреймворка пал на именно Kohana, т.к. в нем реализуется HMVC, ну и вообще, его много хвалят за простоту.
В реальности все оказалось не просто, но особенно напрягало отсутствие изолированности триад MVC, триады разбивались на части и помещались в разные папки. В моем понимании, триада
Model-View-Controller, должны быть изолированны от других триад, и находиться в одной папке, конечно, это можно было реализовать в Kohana, но все будет выглядеть очень «коряво» и запутанно. Еще было не понятно, почему не используется такая замечательная возможность
PHP как пространство имен? Просмотрел еще несколько HMVC-фреймворков, но не к одному «душа не легла». Тогда я решил самостоятельно реализовать HMVC.
Сразу установил несколько директив:
- Должно использоваться пространство имен
- Автозагрузка классов работает на пространстве имен
- В автозагрузку можно добавлять несколько папок
- Каждое приложение имеет свою папку, на которую устанавливается автозагрузка
- Каждая триада, в том числе и шаблоны, помещается в отдельную папку, соответственно, находятся в своем пространстве имен
- По умолчанию, части MVC называются своими именами, Controller, Model и View, в каждой папке триады должна быть папка templates для шаблонов
- Очень простой роутинг, URI просто разбивается в массив
- Controller похож на Kohana_Controller
- Controller получает информацию о том, что от него хотят в конструкторе, разбирает информацию URI-массива, после чего запускает метод action()
- Метод action() проверяет методы объекта и запускает соответственно action_действие()
- Генерация HTML, осуществляется методом контроллера render()
Потом добавил еще несколько:
- Роутинг осуществляет расширенный контроллер, он разбивает URI в массив, сначала проверяет свои actions, если не находит, то ищет зарегистрированный контроллер
- Результат работы модели сохраняется в контроллере, передается в View, при создании в методе контроллера render()
- Метод action() публичный, созданный контроллер можно еще раз запустить и сгенерировать HTML
- View похож на Kohana_View, для приложения, View необходимо «вытащить» в глобальное пространство имен при помощи наследования, заодно немного настроив, все остальные View должны быть наследниками глобального View
- Контроллеры и View должны знать в какой папке и в каком пространстве имен они находятся, для этого они наследуются от специального класса NameSpaceAdapter, это нужно для правильного поиска View из контроллера, а так же папки templates из родительского View
- Главный шаблон для каждой триады — template.php
- Контроллеры автоматически передают в View свой action, на основании этой информации View из главного шаблона template.php самостоятельно ищет нужный шаблон action.php, поэтому не должно быть action_template(), это приведет к зацикливанию шаблонов
- Для администрирования можно создать шаблоны с префиксом admin_action.php, которые можно вызвать только если установлена константа ADMIN
В итоге получилась небольшая HMVC структура,
Model не играет роли, поэтому код не привожу, скажу только, что склоняюсь к статическому классу.
При разработке приложений с модульной структурой на JavaScript возникает две проблемы:
