Where to validate and process form submission in MVC website

Question

I\'m working on a PHP based Model-View-Controller structured website. I understand that the Models should deal with business logic, views present HTML (or whatever) to the u

Answer 1

From my point of view and the way we're doing it at work, model will handle the validation and filtering of datas that are passed to it, but we use the controller to push thoose datas inside the model.

Has stated in above comments, the model don't have to know about $_POST or $_GET these are user input that the controller has to deal with. In the other hand the model must handle all verification of datas passed to it as you definitely don't want to make again and again your data validation in different code portion of your project.

Answer 2

Put shortly, you can use either of these approaches - but you should change them a bit.

Consider this: The models don't really "know" about post, get and whatnot. They should only know about whatever business-related thing they are - in your case a user.

So while approach #1 can be used, you should not access post variables directly from the model. Instead, make the function take an array of parameters which are then used to create the user.

This way you can easily reuse the code, say in a shell script or whatever, where there is no such thing as $_POST.

While the second approach is more verbose in the controller, it's something you could do too. However, perhaps a bit better approach in the style is to use a "service class". The service would have a method, let's say "createUserFromArray", which takes an array and returns a user. Again, you would pass this method the $_POST as parameters - similar to how you should pass them into the function in modified #1.

Only the controller should deal with inputs directly. This is because the controller handles the request, and thus it can know about post.

tl;dr your models should never use superglobals like $_POST directly.

Answer 3

A big reason for the MVC design pattern is that it's a good way of maintaining Separation of Concerns. The View should be ignorant of the Model, and vice-versa. The Controller is there only as a sort of traffic cop mediating between the Model and the View. So the Controller should take the data from the View, do the minimal processing needed so that the Model can understand the data without needing to know how the View is implemented (i.e. via an HTML form), and give it to the Model so the model can persist the data.

This makes it so the Model can be reused in other instances when an item needs to be created / saved / persisted by other means than an HTML form, without duplicating item-saving code across multiple Controllers.

UPDATE: I forgot to mention validation. Along the same lines as for persisting the data, the Controller should take the data and pass it to the Model for validation, since the Model is the one that knows the exact format of the data it needs. You could combine validation and persistence by having the Model throw an exception if the data is invalid, which the Controller can catch and deal with as necessary (e.g. render JSON error response.)