Does user input go to the controller or model?

Question

Right now I have my model split out, but my controller and views are still combined in a 12k line file. I've been looking to create a true MVC system for this, splitting out the views, but while looking for stuff to split out, I've noticed my controller is doing a lot of work that might belong in a model.

For example, let's say I have...

if (isset($_POST['write'])) {
    $obj = $objManager->get($_POST['id']);
    $obj->setFoo($_POST['foo'])
        ->setBar($_POST['bar']);
    $objManager->write($obj);
    echo ... 
}

... so the stuff after echo, we know goes into a view template. The manager is my model. So my question is, do I do all the reading from $_POST and setting up the data in the controller? Or do I somehow put that into the model, like so...

if (isset($_POST['write'])) {
    $objManager->update($_POST);
    echo ...
}

... where update() does basically the same thing, sets the variables and saves the thinger.

Answer 1

A good way to think about MVC is to ask yourself, "If I changed X in the view layer what would I have to change in the Controller or the Model layers?"

Ideally, the Model layer should be able to exist independent of the View layer, since it functions as the core API of your application. Changes to a view should not require rework in the model.

The Controller is what takes external input (like from the user), calls into the Model layer to process it, and then determines which view to provide as a response.

In your example, $_POST contains the raw input, and the keys in the $_POST array are specified by how they are encoded in your mostly HTML views. You should not expect your model to know what the valid keys are in $_POST or whether the values need to be sanitized, transformed, etc. Leave that job to the controller, which should guarantee that the values it hands off to the model will meet the conditions that the Model layer classes/functions expect.

Answer 2

Your first example looks like the better solution to me. It properly separates the tasks of accepting user input from accessing the data in your model. In other words, the model doesn't care about the fact that the input is coming from POST parameters.

In the second example, you are tightly coupling the model with the controller because the model expects that a list of POST parameters be passed to it in order to update the object. The model shouldn't have to care about where the "id", "foo", and "bar" variables are coming from.

The second example looks a little more elegant, but it is not as friendly to unit testing. In order to unit test it, you would have to pass it an associative array, whose keys match the names of the POST parameters. This is not as big of a deal in PHP, since everything is dynamically typed, but it's one extra thing you have to worry about.

Answer 3

It's fairly common to have the controller take care of all the user input, and stay out of the $_POST variable inside the model, and rather have the controller populate the model. To get more perspectives on the MVC approach, you could have a look at how other frameworks do it, E.G. the Zend Framework