Входит ли пользовательский ввод в контроллер или модель? - PullRequest
2 голосов
/ 06 мая 2011

Сейчас моя модель разделена, но мой контроллер и представления по-прежнему объединены в 12-строчный файл. Я искал для этого настоящую систему MVC, разделяя представления, но, ища вещи для разделения, я заметил, что мой контроллер выполняет много работы, которая может принадлежать модели.

Например, допустим, у меня есть ...

if (isset($_POST['write'])) {
    $obj = $objManager->get($_POST['id']);
    $obj->setFoo($_POST['foo'])
        ->setBar($_POST['bar']);
    $objManager->write($obj);
    echo ... 
}

... поэтому материал, который мы знаем после echo, входит в шаблон представления. Менеджер моя модель. Итак, мой вопрос, я делаю все чтение из $ _POST и настройку данных в контроллере? Или я как-то вставлю это в модель, вот так ...

if (isset($_POST['write'])) {
    $objManager->update($_POST);
    echo ...
}

... где update() делает то же самое, устанавливает переменные и сохраняет указатель.

Ответы [ 3 ]

1 голос
/ 06 мая 2011

Хороший способ подумать о MVC - спросить себя: «Если бы я изменил X в слое вида, что бы мне пришлось изменить в слоях Controller или Model?»

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

Контроллер - это то, что принимает внешний ввод (например, от пользователя), вызывает на уровне модели, чтобы обработать его, а затем определяет, какое представление предоставить в качестве ответа.

В вашем примере $ _POST содержит необработанный ввод, а ключи в массиве $ _POST определяются тем, как они закодированы в ваших представлениях в основном HTML. Вы не должны ожидать, что ваша модель будет знать, какие действительные ключи находятся в $ _POST или нужно ли значения, которые необходимо обработать, преобразовать и т. Д., Оставьте это задание контроллеру, что должно гарантировать, что значения, которые он передает модели, будут соответствовать условия, которые ожидают классы / функции уровня модели.

1 голос
/ 06 мая 2011

Ваш первый пример выглядит как лучшее решение для меня. Он должным образом отделяет задачи принятия пользовательского ввода от доступа к данным в вашей модели. Другими словами, модель не заботится о том факте, что ввод поступает из параметров POST.

Во втором примере вы тесно связываете модель с контроллером, потому что модель ожидает, что ей будет передан список параметров POST для обновления объекта. Модель не должна заботиться о том, откуда берутся переменные "id", "foo" и "bar".

Второй пример выглядит немного более элегантно, но он не так удобен для модульного тестирования. Чтобы выполнить его модульное тестирование, вам нужно будет передать ему ассоциативный массив, ключи которого соответствуют именам параметров POST. Это не так уж сложно в PHP, поскольку все динамически типизировано, но это еще одна вещь, о которой вам нужно беспокоиться.

1 голос
/ 06 мая 2011

Довольно часто контроллер контролирует все вводимые пользователем данные и не попадает в переменную $ _POST внутри модели, а контроллер заполняет модель. Чтобы узнать больше о подходе MVC, вы можете посмотреть, как это делают другие фреймворки, E.G. Zend Framework

...