What is the right way to handle $_POST data in MVC?

Question

I have the common MVC situation in my PHP system: the Controller receive a request from the View containing $_POST data. Now I have three ways to handle the data:

a) The Controller only calls the Model and the Model handle the $_POST data.
b) The Controller transforms the $_POST data into variables and pass them to Model.
c) The Controller transforms $_POST data into a Model's domain object and only pass the object to Model.

Currently, I am following option A, but I believe it is wrong, so I am thinking of using option C.

So, according to MVC, what is the right way to handle $_POST data?

EDIT At the moment, I'm not using any MVC framework.

EDIT 2 Generally, the same Controller handles request from a browser, a web service, an offline application, etc, or each one has it own Controller?

Answer 1

The best option is to use #2 approach, with some alterations.
I would write it as something like this:

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

There is no need to actually create variables, if you have used something like a Request instance to abstract the user's input.

_{Also, you might want to replace theRequest::getParam()method with something likeRequest::getPost()- although I have come to the conclusion that, in a correctly structured application, theGETandPOSTparameters should not share same name.}

The serviceFactory which you see in the code snippet would be an object that you inject in both controller and view instance. It would let you share same service instances between controllers and views.

It is responsible for creation of services (which would contain the application logic, while leaving the domain business logic in the domain objects), which helps you isolate the interaction between domain entities and storage abstractions from the presentation layer.

About the other options:

• The Controller only calls the Model and the Model handle the $_POST data.

  In the MVC and MVC-inspired design patterns the model should be aware of neither the user interface nor of the presentation layer as whole. The $_POST variable in PHP is a superglobal.

  If you use it with model layer, your code becomes bound to the web interface and even the specific request method.

• The Controller transforms $_POST data into a Model's object and only pass the object to Model

  Not entirely sure what you meant with this. Seems you were talking about instantiation of an abstraction, which would contain the user's request. But in this case controller becomes responsible for instantiation/creation of said structure, which would violate SRP.

Closing notes:

One thing you must understand is that, in context of web based MVC applications, the User of your application is the browser. Not you. Browser sends the request, which is handled by routing mechanism and disseminated by controller. And view produces the response to your browser.

And the other thing is: Model is neither a class nor an object. Model is a layer.

---

Update

Generally, the same Controller handles request from a browser, a web service, an offline application, etc, or each one has it own Controller?

You should be able to have single controller, that deals with all the forms of application. But that is only on the condition, you are actually using same application for all 3 use-cases.

To do so there are two conditions:

• you need to abstract the Request instance, that controller receives
• the view should be instantiated outside the controller

This way you can have one application to fulfill all the requirements. Only thing, that each variant has different, is the bootstrap stage, where you create the Request instance and select the proper view.

In the situation, that you described, the changing part would actually be the view, since a REST or SOAP service would be expected to produce a different response than an ordinary web application.