MVP: должен ли докладчик выполнять задачи начальной загрузки?
Я конвертирую сделанный на заказ сайт PHP, чтобы использовать MVP. Это предпочтительнее для меня, чем MVC. Плюс, на мой взгляд, большинство уроков и фреймворков, претендующих на звание MVC.
Во всяком случае, мой сайт сайт имеет загрузчик, который содержит:
- Автозагрузчик PSR-0 для пространств имен
- Жестко закодированная конфигурация, которая никогда не изменится (все в ассоциативном массиве
$settings) - Создание общих объектов, таких как соединение с базой данных, очиститель переменных, форматтер и т. Д.
- Подключение к базе данных
- Загрузка настроек из базы данных (редактируется в CMS)
- URL-маршрутизация
В MVP презентатор «возьмет на себя» начальную загрузку и выполнит какую-либо из этих задач?
Если я правильно понимаю MVP, Presenter должен быть классом, который обрабатывает весь пользовательский ввод, так что это будет включать в себя маршрутизацию URL. Другие пункты, мне кажется, больше похожи на ответственность начальной загрузки. Единственное, что меня беспокоит, — это вставить все эти объекты и настройки в Presenter.
Решение
ТЛ; др Используйте AppController верхнего уровня, который обрабатывает маршрутизацию и настройку, необходимую для всех страниц, и оставьте докладчика для вещей, связанных с определенной страницей / представлением.
Используйте контроллер верхнего уровня для общих вещей
это GWT MVP учебник имеет дополнительный AppController, который обрабатывает все вещи, не относящиеся к определенному представлению / докладчику. Я считаю это хорошей идеей. Хотя GWT для клиентской стороны, тот же принцип может быть использован на сервере.
Докладчик в MVP довольно специфичен для определенного представления, и он должен общаться только с представлением и моделью (или их соответствующими интерфейсами), в то время как все ваши элементы не являются специфическими для конкретной страницы / представления. Если вы помещаете все это в «презентатор», то вы неправильно используете презентатор как контроллер в «Web MVC».
пример
Например, AppController может выбрать правильный презентатор на основе параметров HTTP (т. Е. Маршрутизации), установить соединение с БД и загрузить другие общие настройки. Затем объект соединения может быть передан докладчику, который знает, как создать правильный вид и модель, и передать соединение с моделью. Представитель и докладчик не должны ничего знать о соединении, и модель не должна зависеть от какой-либо реализации, просто нужно внедрить интерфейс.
настройки
Загрузка настроек из базы данных (редактируется в CMS)
Это звучит так, как будто оно должно принадлежать модели. Модель знает, какие настройки ей нужны, и может их попросить. Если настройки связаны с пользовательским интерфейсом, то докладчик или представление должны запросить их. Если это чисто визуальный материал, то он переходит в представление, но если это «логика отображения», то он принадлежит презентатору, так как в MVP представление не должно иметь никакой логики.
Другие решения
Других решений пока нет …