Прямо сейчас у меня отключена моя модель, но мой контроллер и представления все еще объединены в 12-строчный файл. Я искал для создания настоящей MVC-системы для этого, разделив представления, но, глядя на разрывы, я заметил, что мой контроллер выполняет большую работу, которая может принадлежать модели.
Например, допустим, у меня есть …
if (isset($_POST['write'])) { $obj = $objManager->get($_POST['id']); $obj->setFoo($_POST['foo']) ->setBar($_POST['bar']); $objManager->write($obj); echo ... } … так что материал после эха, мы знаем, входит в шаблон представления. Менеджер – моя модель. Итак, мой вопрос: я все читаю из $ _POST и настраиваю данные в контроллере? Или я как-то поместил это в модель, вот так …
if (isset($_POST['write'])) { $objManager->update($_POST); echo ... }
… где update() делает в основном одно и то же, устанавливает переменные и сохраняет предмет.
Ваш первый пример выглядит как лучшее решение для меня. Он правильно отделяет задачи приема пользовательского ввода от доступа к данным в вашей модели. Другими словами, модель не заботится о том, что вход поступает из параметров POST.
Во втором примере вы жестко связываете модель с контроллером, потому что модель ожидает, что список параметров POST будет передан ей для обновления объекта. Модель не должна заботиться о том, откуда берутся переменные «id», «foo» и «bar».
Второй пример выглядит немного более элегантным, но он не так дружелюбен к модульному тестированию. Чтобы проверить его на единицу, вам придется передать ему ассоциативный массив, ключи которого соответствуют именам параметров POST. Это не такая большая сделка в PHP, поскольку все динамически типизировано, но это одна дополнительная вещь, о которой вам нужно беспокоиться.
Достаточно распространено, что контроллер заботится обо всех пользовательских вводах и не входит в переменную $ _POST внутри модели, и, скорее, контроллер заполняет модель. Чтобы получить больше взглядов на подход MVC, вы можете посмотреть, как это делают другие фреймворки, EG Zend Framework
Хороший способ подумать о MVC – спросить себя: «Если бы я изменил X на уровне представления, что мне пришлось бы менять в слоях Controller или Model?»
В идеале, слой модели должен иметь возможность существовать независимо от слоя «Вид», поскольку он функционирует как основной API вашего приложения. Изменения в представлении не требуют переделки в модели.
Контроллер – это то, что принимает внешний вход (например, от пользователя), вызовы в слой модели для его обработки, а затем определяет, какое представление предоставлять в качестве ответа.
В вашем примере $ _POST содержит исходный ввод, а ключи в массиве $ _POST определяются тем, как они кодируются в основном HTML-представлениях. Вы не должны ожидать, что ваша модель узнает, какие действительные ключи находятся в $ _POST, или нужно ли их дезинфицировать, трансформировать и т. Д. Оставьте это задание контроллеру, который должен гарантировать, что значения, которые он передает, будут соответствовать условия, которые ожидают классы / функции класса модели.