Что это
Вот что я сделал до сих пор:
- ядро /
- контроллеры / (содержит контроллеры, используемые приложением)
- models / (содержит модели, используемые приложением)
- views / (содержит представления, используемые приложением)
- base_controller.php (каждый контроллер расширяется)
- base_model.php (каждая модель расширяется)
- поставщики /
- phprouter / (простой класс маршрутизатора)
- прыщ / (простой класс контейнера DI)
- configuration.php (содержит всю конфигурацию приложения)
- index.php (включает конфигурацию, поставщиков, базовую модель, базовый контроллер, устанавливает контейнер DI вверх и направляет запрос)
Смотрите код здесь: http://pastebin.com/pxUpUvv6
Обратите внимание, что данный код является всего лишь примером, поэтому контроллеры, модели, представления еще не созданы. Кроме того, он может быть ошибочным – как непроверенный, но сейчас это не имеет значения.
Поток запроса
- Клиент запрашивает index.php .
- Сюда входят конфигурация, поставщики, базовый контроллер, базовая модель.
- Контейнер DI и зависимости инициализируются, теперь мы можем их вводить в любом месте.
- Мы сопоставляем контроллеры с URL-адресом, и маршрутизатор выполняет свою работу.
- Контроллер извлекается (хотя это не в примерном коде, как указано выше).
- Мы делаем кое-что.
- Затем метод вызывает
::call_model() , который включает соответствующую модель из ядра / моделей / , а затем вызывает тот же метод, который мы используем из соответствующего класса модели.
- Модель загружена.
- Больше вещей.
- Затем модель вызывает
::call_view() ', которая включает соответствующий вид из core / views / .
- Представление извлекается и отображает страницу клиенту.
FYI: Соответствующие
Примеры контроллера, модели, вида, которые соответствуют:
- Контроллер
Controller_Products::list() в ядре / контроллерах / Controller_Products.php
- Model
Model_Products::list() качестве ядра / моделей / Model_Products.php
- Просмотр в ядре / views / Model_Products_list.php
Проблемы, с которыми сталкиваются
На самом деле, я чувствую себя немного неудобно с этой структурой. Dunno, кажется, далек от масштабируемого, modulable …
- Создает ли только основную структуру папок –
core{, /controllers, /models/, /views} , vendors в корне?
- Мне кажется, что я должен получить
__autoload() вне index.php , что кажется мне слишком большим. Если да, то как насчет контейнера DI?
- Может быть, если мне понадобится больше двух внешних библиотек, лучше не включать их один за другим вручную? Но как?
- Ввод всей конфигурации в файл configuration.php в корне выглядит для меня как старомодный PHP4. Благодаря силе Pimple я мог встроить эту конфигурацию прямо в нее, но все же, где?
- Я думаю, что способ, которым я обрабатываю
::call_model() ( core / base_controller.php ) и ::call_view() ( core / base_model.php ), немного неудобен . Согласитесь? Что было бы упрощенным способом переделать все это?
- Учитывая все мои проблемы, будет ли в конечном итоге лучше использовать фреймворк в качестве Symfony?
Если что-то неясно, не стесняйтесь спрашивать.
Благодарю.
- Да.
- Вы можете использовать контейнер автозагрузки и DI вместе. Например , как можно использовать автозагрузку с соглашением об именах. Я рекомендую использовать spl_autoload.
- С автозагрузкой вы можете удалить все (или почти все).
- По-моему, в index.php.
- Да, это неправильно. Прежде всего, старайтесь не использовать статические методы. Кроме того, модели должны иметь методы с описательными именами, а не просто «позвони мне, и я сделаю все, что смогу». Это более сложная проблема – вам нужно понять, как Controller и Model должны сотрудничать. В качестве варианта прочитайте несколько книг. Контроллер должен вызывать методы модели, чтобы получить данные для некоторой ситуации. Модель – это не просто место для кода контроллера. Различные контроллеры могут использовать разные модели. Модели тоже могут использовать другие модели.
- Ответ на этот вопрос не может быть объективным 🙂