Каков правильный способ обработки данных $_POST в MVC?

Ответ 1

Лучшим вариантом является использование подхода # 2 с некоторыми изменениями.
Я бы написал это как-то вроде этого:

public function postLogin( $request )
{
     $service = $this->serviceFactory->build('Recognition');
     $service->authenticate( $request->getParam('username'),
                             $request->getParam('password') );
}
// Yes, that the whole method

Нет необходимости создавать переменные, если вы использовали что-то вроде экземпляра Request для абстрагирования ввода пользователя.

_{Кроме того, вы можете заменить метод Request::getParam() на что-то вроде Request::getPost() - хотя я пришел к выводу, что в правильно структурированном приложении параметры GET и POST должны не использовать одно и то же имя.}

serviceFactory, который вы видите в фрагменте кода, будет объектом, который вы вводите как в экземпляр контроллера, так и в виде. Это позволит вам совместно использовать те же экземпляры службы между контроллерами и представлениями.

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

О других параметрах:

• Контроллер вызывает только модель и модель с данными $_POST.

  В шаблонах дизайна MVC и MVC модель не должна знать ни интерфейса пользователя, ни уровня представления в целом. Переменная $_POST в PHP - это superglobal.

  Если вы используете его с уровнем модели, ваш код привязывается к веб-интерфейсу и даже к определенному методу запроса.

• Контроллер преобразует данные $_POST в объект Model и передает объект только Model

  Не совсем уверен, что вы имели в виду с этим. Кажется, вы говорили о создании абстракции, которая будет содержать запрос пользователя. Но в этом случае контроллер становится ответственным за создание/создание указанной структуры, что нарушит SRP.

Примечания к закрытию:

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

Иная вещь: Модель не является ни классом, ни объектом. Модель - это слой.

Update

Как правило, тот же контроллер обрабатывает запрос от браузера, веб-службы, автономного приложения и т.д., или у каждого есть свой собственный контроллер?

Вы должны иметь один контроллер, который имеет дело со всеми формами приложения. Но это только при условии, что вы фактически используете одно и то же приложение для всех 3 случаев использования.

Для этого существуют два условия:

• вам нужно отвлечь экземпляр Request, который получает контроллер
• представление должно создаваться вне контроллера

Таким образом, вы можете иметь одно приложение для выполнения всех требований. Единственное, что каждый вариант имеет разные, это этап начальной загрузки, где вы создаете экземпляр Request и выбираете правильный вид.

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

Ответ 2

Когда-то была трехуровневая архитектура приложения.

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

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

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

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

Интересный вопрос: как вы относитесь к действиям, воздействующим на несколько объектов домена? Куда вы вкладываете в это логику?

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

Symfony2, например, дает разумный ответ на этот вопрос: каждый шаг обработки запроса реализуется в выделенном фрагменте кода, который можно охарактеризовать следующим образом:

• запрос сначала превращается в объект
• этот объект маршрутизируется с использованием объекта маршрутизации
• обрабатывается контроллером
• контроллер передает запрос службе, связанной с действием, которое создает объект ответа

Затем служебное задание разбивается на несколько этапов:

• проверка (с использованием выделенного объекта, который опирается на правила, описанные в отдельном файле),
• построение/обновление объектов домена (при необходимости, с использованием сериализации в/из db),
• выбор шаблона для ответа,
• совокупность указанного шаблона с соответствующими данными из доменов.

CakePHP - еще одна популярная структура, которая следует за аналогичными понятиями: простые контроллеры и сервисы, инкапсулирующие объекты домена.

См. этот вопрос для лучшего понимания общих понятий.

См. этот другой вопрос для других ответов.

Благодаря tereško за бесценный вклад в дело.

Ответ 3

Я использую Zend и следую за

второй вариант.

Пример регистрационной формы

step-1 формы отправляют мне значение post указанному контроллеру

Шаг -2 Я буду проверять значения формы, например (почтовые и URL-адреса и пустые значения сообщений) с помощью проверки на стороне сервера.

шаг -3 отправить данные проверенных сообщений либо в переменную, либо целую модель.

шаг 4 - контроллер вызывает модель.

шаг -5 модели вставляют значения post и создают нового пользователя.

Я думаю, что ваш второй вариант лучше, независимо от того, какой рамки вы используете.

note - тот же контроллер может обрабатывать все, что зависит от вашей логики приложения.

 but i prefer to keep different controller for differnt user request and user types

 it helps in keeping code readable managebale .

Ответ 4

Посмотрите на некоторые рамки MVC.

Например, в Yii вы можете написать такой код внутри action:

$model = new Model();
if(isset($_POST['Model'])) {
    $model->attributes = $_POST['Model'];
}

Обратите внимание, что все attributes вашей модели должны проходить через правила проверки. В Yii валидация применяется во время (фактически, до) $model->save()

Смотрите:

• http://www.yiiframework.com/doc/guide/1.1/en/form.model#securing-attribute-assignments
• http://www.yiiframework.com/doc/guide/1.1/en/basics.mvc

Ответ 5

'C' - лучший вариант. Вы не должны пропускать необработанные данные POST в модель, поскольку предполагается, что модель будет основным хранилищем и загрузкой в ​​основном.

Пример: в той же модели можно использовать веб-интерфейс и веб-службы. В Интернете $_POST действителен, но для веб-служб его нет. Таким образом, модель не заботится о том, как принимаются данные, но только как ее хранить и загружать.

Yii определенно является чистой реализацией MVC.