Как правильно обрабатывать данные $ POST в MVC?

у меня есть общая ситуация MVC в моей системе PHP:Controller получить запрос от View С $_POST данные. Теперь у меня есть три способа обработки данных:

a)Controller только называет Model и Model обработки $_POST данные.
б)Controller превращается в $_POST данные в переменные и передать их в Model.
c)Controller преобразование $_POST данные в Modelобъект домена и только передать объект Model.

в настоящее время я следую варианту A, но я считаю, что это неправильно, поэтому я думаю об использовании опции C.

Итак, согласно MVC, каков правильный способ обработки $_POST данные?

редактировать на данный момент я не использую фреймворк MVC.

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

5 ответов


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

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

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

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

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

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

о других вариантах:

  • контроллер вызывает только модель, а модель обрабатывает данные $_POST.

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

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

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

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

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

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

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


обновление

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

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

для этого есть два условия:

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

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

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


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

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

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

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

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

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

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

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

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

задание службы затем разбивается на несколько шагов:

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

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

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

посмотреть это другой вопрос другие ответы.

спасибо tereško за его неоценимый вклад в дело.


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

2-й вариант .

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

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

шаг -2 Я проверю значения формы, например (mail и url и пустые значения post), через проверку на стороне сервера .

шаг -3 отправить проверенные данные post либо в переменной или имеет весь модели .

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

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

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

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

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

 it helps in keeping code readable managebale .

посмотрите на некоторые фреймворки MVC.

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

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

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

посмотреть:

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

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

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

Yii, безусловно, является чистой реализацией MVC.