Можно ли вызвать модель из представления?

Вместо того, чтобы использовать полномасштабный PHP MVC, я разрабатываю тот, который лучше всего подходит для моих целей. У меня есть базовая структура, и я закодировал модели и контроллеры, которые мне нужны для запуска моего веб-сайта.

Теперь я перехожу к представлениям, и я столкнулся с небольшой дилеммой. Мой подход работает отлично для меня, но для будущей ссылки я хочу знать, является ли то, что я делаю, это плохая привычка.

То, что я пытаюсь сделать:

В моем представлении я вызываю модель, которая запускает мою систему аутентификации, и запрашивает статус входа пользователя. Затем я использую это логическое значение, чтобы решить, показывать ли определенные элементы в представлении и куда поместить других.

Должен ли я разрабатывать отдельные виды для каждого состояния входа, или этот подход прекрасен? Однако, если я собираюсь внедрить этот MVC в работу, которую я делаю для своих клиентов, мне нужно использовать лучшие практики.

Любой совет будет принят во внимание!

Solutions Collecting From Web of "Можно ли вызвать модель из представления?"

Могу ли я вызвать модель из представления?

Да, ты можешь. Пока вы сохраняете разделение проблем между M, V и C, вы можете обратиться к Модели (или Контроллеру) из представления. Большинство диаграмм MVC показывают двунаправленное соединение, по крайней мере, между View и Model. То, что вы не хотите делать, это разместить логику / код из модели (или контроллера) в представлении, и вы не хотите изменять модель оттуда.

Например, у вас может быть виджет на вашей странице, который объединяет последние десять заголовков заголовков блога из ваших любимых блогов на каждой странице вашего сайта. Вы получаете заголовки, вызывая, скажем, MyFavFeeds::getLatest(); в вашей модели. Какие у вас сейчас варианты?

  1. Вы можете добавить код для извлечения заголовков в контроллер, но это потребует от вас повторения его в каждом действии контроллера, что противоречит принципу DRY. Кроме того, проблема контроллера связана с обработкой пользовательского ввода для конкретных действий, и выборка заголовков для каждого вызова, вероятно, даже не связана с этими действиями.
  2. Если ваша архитектура поддерживает его, вы можете извлечь эти данные в какой-то крюк preDispatch, т. Е. Заголовки загружаются и вводятся в представление из плагина или обратного вызова. Это будет СУХОЙ, но второй разработчик может не знать об этом плагине и случайно перезаписать переменную, содержащую заголовки, из своего действия с контроллером. И могут быть случаи, когда вы не хотите загружать заголовки, например, когда вы просто показываете страницы подтверждения для представлений форм, поэтому тогда вам придется иметь механизм отключения плагина. Это много, чтобы рассмотреть.
  3. Вы помещаете вызов (не код) MyFavFeeds::getLatest() в шаблон View или Layout или, лучше, ViewHelper, который инкапсулирует вызов вашему классу модели и отображает виджет. Таким образом, вам не нужно беспокоиться о перезаписи любых переменных или повторении. И когда вам не нужны заголовки в вашем представлении, вы просто не включаете их.

О вашем другом вопросе:

В моем представлении я вызываю модель, которая запускает мою систему аутентификации, и запрашивает статус входа пользователя. Затем я использую это логическое значение, чтобы решить, показывать ли определенные элементы в представлении и куда поместить других.

Аутентификация – это то, что вы захотите сделать в начале потока приложений до того, как будут вызваны действия контроллера. Таким образом, вы не должны запускать свою (целую) систему аутентификации в представлении. Фактическая аутентификация не является логикой, связанной с просмотром. С другой стороны, просто запрашивать статус пользователя после проверки подлинности. Например, если вы хотите отобразить виджет с указанием имени пользователя и кнопку входа / выхода из системы, было бы неплохо сделать что-то вроде

 <?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; } } 

Если у вас есть большие части вашего графического интерфейса, которые должны быть изменены ролью пользователя, вам может потребоваться разбить ваш взгляд на частичные блоки и включить их на основе статуса вместо того, чтобы записывать весь HTML в помощник представления.

Если вы только хотите сделать навигацию на основе роли пользователя, посмотрите Zend_Navigation Zend Framework и Zend_Acl чтобы посмотреть, как они это делают.

Вы можете , но не должны . За исключением нескольких крайних случаев (и разветвление вашего представления, основанного на зарегистрированном статусе, определенно не является «крайним случаем»), это почти всегда «Плохая идея», чтобы вызывать материал модели из представления.

То, что вы, вероятно, захотите сделать в своей ситуации, – передать логическое представление в контроллер через контроллер. Таким образом, если вы что-то измените о модели пользователя, представление не обязательно должно знать, если контроллер сохраняет поведение одинаково.

Хорошо, я бы постарался сохранить мои представления как можно более логичными. Если вам нужно переключить что-либо на основе, например, результата метода модели, поставьте контроллер на место, который делегирует рендеринг.

Просто убедитесь, что вы следуете основной идее: делайте свои вещи в моделях, расскажите своим моделям, что делать с вашими контроллерами, а также расскажите о своих представлениях, что показывать с ваших контроллеров.

Хотя я знаю только о MVC, чтобы попасть в неприятности, я всегда жил по тому факту, что, если ваше представление не является СТРОГО пользовательским интерфейсом, тогда его не должно быть.

Кроме того, я также столкнулся с идеей тонких контроллеров, толстых моделей.

Исходя из этого, я бы предложил добавить метод вашей модели системы аутентификации, который возвращает соответствующее представление для визуализации и передает его в представление.