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

Question

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

:)

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

Answer 7

Будут ли следующие изменения к DisgruntledGoat's code snippet считаться слишком «сложными»? Должны ли объекты передаваться в представление?

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

А может быть?

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

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

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