Как компоненты MVC сочетаются друг с другом?

Question

Я видел несколько примеров того, как компоненты MVC совмещаются в Интернете.

---

Контроллер получает данные из модели и передает их в представление

Это кажется многословным и грязным.

$model = new Model;
$view = new View;
$view->set('foo', $model->getFoo());
$view->display();

Контроллер передает модель на просмотр

Что если представлению требуются данные из нескольких моделей?

$model = new Model;
$view = new View($model);
$view->display(); //View takes what is needed from the Model

Контроллер передает вид на модель

$view = new View;
$model = new Model($view);
$view->display(); //Model has told the View what is needed

---

Какой из них является «лучшим» способом для достижения цели? Если нет, то что?

Answer 1

Контроллер получает данные из модели и передает их в представление

Как вы сказали, это многословно и грязно. Но это наиболее подходящее решение с философией MVC.

Контроллер передает модель в представление

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

Контроллер передает вид на модель

Забудь об этом. Здесь это грязно.

Answer 2

Ответ на оригинальный вопрос:

1. Контроллер получает данные из Модели и передает их в представление

MVC на самом деле очень аккуратный и чистый. Помните, к чему он обращается:

1. Повторное использование кода (Модели не зависят от контроллеров или представлений. Представления не зависят от контроллеров или моделей. Контроллеры зависят от приложения.)

2. Разделение логики (Например, для изменения серверной части аутентификации с MySQL на LDAP требуется 0 изменений для представления. Изменение структуры представления требует 0 изменений в модели. Изменение структуры таблицы базы данных требует 0 изменений в контроллере или представлении ).

Теперь, ЕСЛИ вы хотите, чтобы ваши формы автоматически генерировались из структуры таблицы - представления теперь привязаны к таблице (тесно связаны). Изменения в таблице требуют изменения в представлении (хотя и потенциально автоматически). Это может занять меньше кода - но представление больше не зависит от точки зрения повторного использования кода.

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

MVC - это строгая 3-уровневая архитектура. Двухуровневая архитектура действительна для некоторых приложений. Для быстрых коллажей и "выполнения дерьма" может подойти одно связная архитектура (но вы не получаете очки стиля).

Надеюсь, это поможет.

Answer 3

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

Если вид относится к конкретной модели, вы можете использовать вариант 2. Если представление предназначено для абстрактной модели (и вы можете использовать ее для отображения информации из набора моделей), используйте параметр 1.

Вариант 3 просто неверен.

Answer 4

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

Статья в Википедии объясняет это довольно хорошо.

Answer 5

ИМХО, вариант 2 ( Контроллер передает модель в представление ) наилучшим образом поддерживает правильное разделение и разделение задач. Если для представления требуется несколько моделей, передаваемая модель должна быть составным типом данных, который содержит каждую модель, необходимую для представления. «Каждая модель, необходимая представлению» обычно отличается от вашей модели сущности тем, что она выровнена и оптимизирована для отображения, часто называемой ViewModel.

Вариант 1 ( Контроллер извлекает данные из модели и передает их в представление ) очень похож на вариант 2, но я утверждаю, что вариант 2 предпочтительнее, поскольку он помещает меньше логики в контроллер. В MVC в модели должно быть как можно больше логики, чтобы ваши контроллеры и представления были максимально простыми.