У меня общая ситуация с MVC в моей системе PHP: Controller получает запрос из View содержащий данные $_POST . Теперь у меня есть три способа обработки данных:
a) Controller вызывает только Model и Model обрабатывающие данные $_POST .
б) Controller преобразует данные $_POST в переменные и передает их в Model .
c) Controller преобразует данные $_POST в объект домена Model и передает объект только Model .
В настоящее время я следую за вариантом A, но я считаю, что это неправильно, поэтому я думаю об использовании опции C.
Итак, согласно MVC, каков правильный способ обработки данных $_POST ?
EDIT На данный момент я не использую рамки MVC.
EDIT 2 Как правило, один и тот же Controller обрабатывает запрос от браузера, веб-службы, автономного приложения и т. Д., Или у каждого есть собственный Controller ?
Лучшим вариантом является использование подхода №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 модель не должна знать ни интерфейса пользователя, ни уровня представления в целом. Переменная $_POST в PHP является суперглобальной .
Если вы используете его с уровнем модели, ваш код будет привязан к веб-интерфейсу и даже к определенному методу запроса.
Контроллер преобразует данные $ _POST в объект модели и передает объект только Model
Не совсем уверен, что вы имели в виду с этим. Кажется, вы говорили о создании абстракции, которая будет содержать запрос пользователя. Но в этом случае контроллер становится ответственным за создание / создание указанной структуры, что будет нарушать SRP .
Одна вещь, которую вы должны понимать, это то, что в контексте веб-приложений MVC пользователь вашего приложения является браузером. Не вы. Браузер отправляет запрос, который обрабатывается механизмом маршрутизации и распространяется контроллером. И представление вызывает ответ на ваш браузер .
И другое: Модель не является ни классом, ни объектом. Модель – это слой .
Как правило, тот же контроллер обрабатывает запрос от браузера, веб-службы, автономного приложения и т. Д., Или у каждого есть собственный контроллер?
Вы должны иметь один контроллер, который имеет дело со всеми формами приложения. Но это только при условии, что вы фактически используете одно и то же приложение для всех трех вариантов использования.
Для этого есть два условия:
Request экземпляр Request , который получает контроллер Таким образом, вы можете иметь одно приложение для выполнения всех требований. Единственное, что каждый вариант имеет разные, – это этап начальной загрузки, где вы создаете экземпляр Request и выбираете правильный вид.
В ситуации, о которой вы описали, изменяющейся частью будет фактически представление, поскольку ожидается, что служба REST или SOAP даст другой ответ, чем обычное веб-приложение.
Когда-то давно была трехуровневая архитектура приложений.
Все зависит от вашей структуры MVC. Обычно контроллер выполняет связь между пользователем и уровнем модели, которые манипулируют объектами домена.
В первые дни MVC в PHP слой модели был фактически просто объектами домена, называемыми моделями для этой цели. Некоторые предпочитают иметь так называемые тонкие модели, которые предоставляют только представление OO данных (что упрощает настойчивость). В этом случае контроллер будет группировать так называемые действия, содержащие основную часть обработки, связанную с HTTP-запросом (контроллер жира).
Другие встроили большую часть указанной обработки в объектную модель с помощью специальных методов (толстая модель).
Однако в какой-то момент вам необходимо проанализировать содержимое запроса для его дезинфекции и проверки, и это зависит от того, как ваше представление будет форматировать запрос. Санитацией может быть задача контроллера (этот запрос должен содержать только эти значения), в то время как проверка является определенно образцовой задачей (значения должны быть из этих типов).
Интересный вопрос: как вы справляетесь с действиями, воздействующими на несколько объектов домена? Куда вы вкладываете в это логику?
В настоящее время модельный слой состоит из сервисов, разделяющих объекты домена от злой хватки контроллеров, для ограничения зависимостей между уровнями только до их соответствующих интерфейсов. Именно здесь выполняется большая часть обработки запроса.
Symfony2 , например, дает разумный ответ на этот вопрос: каждый шаг обработки запроса реализуется в выделенном фрагменте кода, который можно охарактеризовать следующим образом:
Затем служебное задание разбивается на несколько этапов:
CakePHP – еще одна популярная структура, которая следует за аналогичными понятиями: простые контроллеры и сервисы, инкапсулирующие объекты домена.
См. Этот вопрос для лучшего понимания общих концепций.
См. Другой вопрос для других ответов.
Благодаря терешко за бесценный вклад в дело.
Я использую Zend и следую
второй вариант.
Пример регистрационной формы
step-1 формы отправляют мне значение post на указанный контроллер
step -2 i будет проверять значения формы, например (почтовые и URL-адреса и пустые значения сообщений) с помощью проверки на стороне сервера.
шаг -3 отправить данные проверенных сообщений либо в переменную, либо целую модель.
Шаг 4 – контроллер вызывает модель.
step -5 модели вставляют значения post и создают нового пользователя.
Я думаю, что ваш второй вариант лучше, независимо от того, какой рамки вы используете или используете.
note – тот же самый контроллер может обрабатывать все, что зависит от вашей логики приложения.
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()
Видеть:
«C» – лучший вариант. Вы не должны пропускать необработанные данные POST в модель, поскольку в качестве модели предполагается, что в основном используются хранилища и операции загрузки.
Пример: в той же модели можно использовать веб-интерфейс и веб-службы. В Интернете $ _POST действителен, но для веб-служб его нет. Таким образом, модель не заботится о том, как принимаются данные, а только о том, как ее хранить и загружать.
Yii определенно является чистой реализацией MVC.