MVC: Model View Controller - View вызывает модель - PullRequest
6 голосов
/ 12 апреля 2010

Я уже некоторое время читаю о дизайне MVC, и, кажется, официально View вызывает объекты и методы в модели, строит и выводит представление.

Я думаю, что это в основном неправильно.

Контроллер должен действовать и извлекать / обновлять объекты внутри модели, выбирать соответствующий вид и передавать ему информацию, чтобы он мог отображаться. Только грубые и рудиментарные переменные PHP / simple, если в представлении должны появляться операторы.

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

Ответы [ 7 ]

9 голосов
/ 12 апреля 2010

Нет одного абсолютного и правильного способа сделать MVC. Вариации возможны.

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

8 голосов
/ 09 ноября 2010

Как и во всех вещах программирования, мы должны быть прагматичными. Представление должно содержать только логику представления. Эта логика может быть очень простой или довольно сложной. Пока эта логика обрабатывает только то, что отображается на экране, печатается в отчете и т. Д.

Контроллер должен действовать и извлекать / обновлять объекты внутри Модели, выбирать соответствующий Просмотр и передавать ему информацию, чтобы он мог отображаться.

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

Суть спора в том, если вы, с точки зрения, сможете обновить модель напрямую, минуя контроллер. Вот тут-то и прагматичная сторона. Я думаю, что есть случаи, которые могут потребовать непосредственного обновления модели. Особенно, если вы можете использовать привязки данных. Вы можете назначить текстовое поле свойству модели и автоматически выполнить обновление. Если существует множество простых настроек свойств, этот подход может сохранить кучу кода в контроллере. MVC - это не набор правил, установленных в камне. Это правила, которые при правильном использовании могут дать лучший код, но при слишком строгом использовании могут привести к боли и страданиям.

Будьте прагматичны!

3 голосов
/ 13 апреля 2010

Это, вероятно, не то, что можно было бы назвать «чистым» MVC, но ИМХО, это не так уж важно, если PHP-код представления не изменяет модель. Самым важным правилом MVC является то, что модель не знает о представлении. Имея представление о модели не знать, менее важно.

Основным недостатком непосредственного использования модели является то, что представление нельзя использовать повторно с другой моделью. Это редко является проблемой, потому что представление почти всегда специфично для одного конкретного типа объекта модели (или его списка).

2 голосов
/ 08 сентября 2011

Будут ли следующие модификации кода кода DisgruntledGoat считаться слишком "сложными"? Должны ли объекты быть переданы в представление?

<li><?=$item->description?></li>

А может быть?

<li><?=$item->getDescription()?></li>

Я видел несколько примеров, где используются только массивы: -

<li><?=$item['description']?></li>
1 голос
/ 12 апреля 2010

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

Итак, обычно у вас есть контроллер, который является отправной точкой для приложения. В PHP это будет ваш файл index.php. Как минимум этот файл будет обрабатывать входные данные (то есть строку запроса или параметры URL). Обычно рекомендуется добавлять отдельные контроллеры для отдельных частей приложения.

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

Затем вы просто включаете другой файл PHP, содержащий в основном HTML, но с некоторыми переменными, отображающими PHP. Петли тоже хорошо. Если у вас есть список вещей, вы можете сделать что-то вроде этого:

<ul>
<?php foreach ($items as $item) : ?>
  <li><?=$item?></li>
<?php endforeach; ?>
</ul>
1 голос
/ 12 апреля 2010

MVC относится к слоям, а не к компонентам. Таким образом, они являются более абстрактными понятиями, чем чертежами. Поскольку на самом деле невозможно полностью разделить слои (между ними должна передаваться информация), это действительно континуум, в котором у вас есть спагетти с одной системой экстремального и бюрократического типа с другой. Вы, вероятно, хотите найти что-то среднее между этими двумя.

Я обычно не трачу слишком много усилий на разделение вида контроллера. Разделение между моделью и (вид контроллера) гораздо важнее.

1 голос
/ 12 апреля 2010

MVC не является каменным законом. В зависимости от того, где вы читаете об этом, это может отличаться. Лично я не позволяю представлению читать непосредственно из модели.

Обновление Этот пост также имеет несколько хороших примеров. Модель - это двигатель автомобиля с методами start (), вид - это цвет автомобиля с методами paint () или change (), а контроллер - водитель. Я предпочитаю позволять контроллеру вести () машину и запускать () двигатель вместо того, чтобы позволить колесам или краске делать это.

:)

...