Драйверы против контроллеров (MVC)
Я работаю с Codeignitor 2.x, и я изначально использовал контроллеры в качестве модулей (хотя не полностью HMVC), так как у меня был контроллер верхнего уровня, который вызывал бы другие контроллеры нижнего уровня. Я думал, что, поскольку эти контроллеры более низкого уровня все еще взаимодействуют с представлением, они должны оставаться контроллерами, а не моделями или драйверами.
Однако я обнаружил, что каждый экземпляр контроллера также порождает новый экземпляр CI. Таким образом, у меня будет 3 или 4 экземпляра CI для каждого запроса. Тонна накладных расходов, а также вызвала сессионные проблемы.
С тех пор я перенес эти контроллеры более низкого уровня в библиотеку в качестве драйверов. Теперь они захватывают экземпляр CI в методе construct и вносят в него изменения. Это делает работу ОЧЕНЬ приятной и не требует расширения HMVC. Драйверы также не могут вызываться извне, поэтому это позволяет мне направлять все запросы через определенные точки входа.
Мой вопрос, является ли это структурно правильным. Я всегда придерживался мнения, что драйверы должны изменять только те данные, которые они предоставляют через вызовы их методов, но многие из этих драйверов будут извлекать информацию непосредственно из GET и POST, и хотя они не будут напрямую добавляться в View, они часто получают доступ просматривать файлы и передавать обработанный вид экземпляру CI для вывода.
[РЕДАКТИРОВАТЬ] Немного больше контекста: один из драйверов, которые я создал, по сути, является драйвером входа пользователя под названием "Доступ". Он вызывает модель "User" для методов create/login/logout. Драйвер использует данные POST для проверки модели User, затем загружает правильное представление с ошибками и всем необходимым. Идея состоит в том, что с двумя строками я могу включить этот драйвер в любой контроллер на протяжении всего проекта, поэтому значительно снижается избыточность кода. Опять же, я знаю, что драйверы должны быть ограничены их областью действия, однако драйвер не изменяет ничего вне его области действия, а просто возвращает созданное им представление.
Есть ли другой способ для этого, который больше соответствует прямой MVC?
1 ответ
Я не могу сказать, правильно это или неправильно. Но на твоем месте я бы так не поступил. Я, вероятно, рефакторинг некоторого кода. Я хотел бы убедиться, что они не захватывают и не манипулируют данными непосредственно из $_GET или же $_POST Суперглобальные. Вместо этого передайте некоторые данные в качестве аргументов для вызова функции. Это облегчит тестирование, так как вам не нужно имитировать GET или POST запрос. Хотя технически вы можете просто установить значение для суперглобалистов вручную из кода, но я бы не рекомендовал делать это. Предоставление данных в качестве аргументов было бы намного лучше, особенно если вы хотите написать контрольные примеры, которые должны быть выполнены впоследствии. Кроме того, взаимодействие библиотек с областями, выходящими за рамки их собственных, может привести к появлению скрытых ошибок.
По моему мнению, библиотеки должны быть чем-то вроде модулей, где вы можете просто перетаскивать и использовать их без каких-либо хлопот. Если ваш код действительно должен захватывать или манипулировать значениями из $_GET или же $_POST, может быть, они предназначены для моделей. Кроме того, вы можете подумать, является ли ваш код библиотекой или нет. Спросите себя, будет ли этот код полезным за пределами этого приложения? Или это сильно зависит и может быть полезно только для этого конкретного приложения? Если вы скажете "да" последнему, то, вероятно, это должна быть модель, а не библиотека. Последнее, что вы должны оставить вид на контроллер. Просто верните нужные данные из метода библиотеки / модели, а затем передайте их в представление из контроллера.