Я могу назвать Модель от Представления?
Вместо того, чтобы использовать полноценный PHP MVC, я разрабатываю тот, который будет лучшее соответствие мое использование. Мне сделали основную платформу и кодировал модели и контроллеры, я должен буду выполнить свой веб-сайт.
Теперь я перехожу на Представления, и я встретился с маленькой дилеммой. Мой подход хорошо работает для меня, но для дальнейшего использования, я хочу знать, является ли то, что я делаю, дурной привычкой войти.
Что я пытаюсь сделать:
По моему мнению, я называю Модель, которая выполняет мою систему аутентификации и запрос состояния входа в систему пользователя. Я затем использую ту булевскую переменную, чтобы решить, показать ли определенные элементы в рамках представления, и куда разместить других.
Я должен разрабатывать отдельные представления для каждого состояния входа в систему, или действительно ли этот подход прекрасен? Однако, если я собираюсь быть реализацией этого MVC в работу, я делаю для своих клиентов, я должен использовать лучшие практики.
Любой совет ценился бы!
4 ответа
Могу ли я вызвать модель с вида?
Да, можете. Пока вы поддерживаете разделение проблем между M,V и C, вы можете вызывать модель (или контроллер). из "Взгляда". Большинство диаграмм MVC показывают двунаправленное соединение, по крайней мере, между View и Model. Однако, что вы не хотите делать, так это помещать логику/код из Модели (или контроллера) во Вид, и вы не хотите изменять модель оттуда.
Например, на вашей странице может быть виджет, который объединяет последние десять заголовков сообщений в блогах из ваших любимых блогов на каждой странице вашего сайта. Вы получаете заголовки, позвонив, скажем, MyFavFeeds::getLatest(); в вашей модели. Какие у вас теперь есть опции?
- Вы могли бы добавить код для получения заголовков в контроллер, но это потребовало бы повторить его в каждом действии контроллера, что противоречит принципу DRY. Кроме того, контроллер обеспокоен тем, что обрабатывает пользовательский ввод для определённых действий и получение заголовков при каждом вызове, скорее всего, даже не связано с этими действиями.
- Если ваша архитектура поддерживает это, вы можете получить эти данные в каком-нибудь преддиспетчерском крюке, то есть заголовки загружаются и вставляются в View из плагина или обратного вызова. Это было бы DRY, но второй разработчик может не знать об этом плагине и случайно перезаписать переменную, удерживающую заголовки от действия его контроллера. И могут быть случаи, когда вы не захотите загружать заголовки, например, когда вы просто отображаете страницы подтверждения для форм, так что вам придется иметь механизм для отключения плагина тогда. Это очень много для рассмотрения.
- Вы помещаете вызов (а не код)
MyFavFeeds::getLatest()в шаблон View или Layout или, лучше всего, ViewHelper, который инкапсулирует вызов к вашему классу модели и выводит виджет. Таким образом, вам не нужно беспокоиться о перезаписи каких-либо переменных или повторении. А когда вам не нужны заголовки на вашем представлении, вы просто не включаете его.
О другом вашем вопросе:
В моем представлении я вызываю модель, которая запускает мою систему аутентификации, и запрос статуса пользователя для входа в систему. Затем я использую этот логин, чтобы решить. показать ли некоторые элементы в пределах видимости, и где разместить Другие.
Аутентификация - это то, что вы захотите сделать на ранней стадии потока приложений, до того, как будут вызваны какие-либо действия контроллера. Таким образом, вам не следует запускать вашу (всю) систему аутентификации в View. Действительная аутентификация не является логикой, связанной с View. С другой стороны, просто запрос статуса пользователя после аутентификации - это нормально. Например, если вы хотите отобразить виджет, показывающий имя пользователя и дающий кнопку входа/выхода из системы, было бы неплохо сделать что-нибудь вроде
<?php //UserHelper
class UserMenuHelper
{
public function getUserMenu()
{
$link = '<a href="/user/logout">Logout</a>';
if(MyAuth::userHasIdentity()) {
$link = sprintf('<a href="/user/logout">Logout %s</a>',
MyAuth::getUsername());
}
return $link;
}
}
Если у вас есть большие части GUI, которые должны быть изменены ролью пользователя, вы можете захотеть разбить View на частичные блоки и включить их на основе статуса, вместо того, чтобы записывать весь HTML в View Helper.
Если вы ищете только навигацию, основанную на роли пользователя, посмотрите на Zend Framework's Zend_Navigation и Zend_Acl, чтобы увидеть, как они это делают.
Хорошо, я бы действительно постарался сохранить мои "Взгляды" как можно более свободными от логики. Если вам нужно что-то поменять, например, результат модельного метода, установите контроллер, который делегирует рендеринг.
Просто убедитесь, что вы следуете основной идее: Делайте свои вещи в моделях, говорите своим моделям, что делать с контроллеров, а также говорите своим представлениям, что показывать с контроллеров.
Вы можете , но вы не должны . За исключением нескольких экстремальных случаев (и разветвление вашего вида на основании статуса входа в систему определенно не является "экстремальным случаем"), это практически всегда Плохая Идея - вызывать модели из вида.
Что вы, вероятно, хотите сделать в своей ситуации, так это передать булевы к виду через контроллер. Таким образом, если вы что-то измените в Пользовательской модели, вид не должен знать, при условии, что поведение контроллера остаётся прежним
.Хотя я знаю о MVC достаточно, чтобы попасть в неприятности, я всегда жил тем, что если ваш вид не является STRICTLY пользовательским интерфейсом, то его там не должно быть.
Также, я работал с идеей тонких контроллеров, толстых моделей.
Отказавшись от них, я бы предложил добавить метод к вашей модели системы аутентификации, который возвращает соответствующий вид для рендеринга и передает его в вид.
.