MVC: Model View Controller – просматривает ли View модель?

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

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

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

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

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

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

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

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

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

Существует не один абсолютный и правильный способ делать MVC. Возможны вариации.

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

Вероятно, это не то, что можно назвать «чистым» MVC, но IMHO это не огромная сделка, если PHP-код представления не мутирует модель. Наиболее важным правилом MVC является то, что модель не знает о представлении. Не менее важно иметь представление о модели.

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

Могут ли следующие изменения фрагмента кода DisgruntledGoat считаться слишком «сложными»? Должны ли объекты передаваться в представление?

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

Или, может быть?

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

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

 <li><?=$item['description']?></li> 

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

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

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

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

🙂

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

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

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

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

 <ul> <?php foreach ($items as $item) : ?> <li><?=$item?></li> <?php endforeach; ?> </ul>