Where does input validation happen in MVC?

问题:

Ok, this has probably been asked before but i cant find a definative answer. Where in the MVC pattern should validation of input happen?

I would like to say that things like empty fields and basic general validation should happen in the controller and that rules as lengths and valid characters of for example usernames / passwords etc should happen at the model layer.

However, this means spreading this burdon around the application which surely cant be good either?

Sorry if this question is naieve but I am relatively new to this type of programming and want to get things correct from the start.

回答1:

Validation is the job of the model.

As models have various attributes (fields), only the models can know what combination of inputs make that model valid. It's not just about whether a field is blank, or the input of that field matches some pattern, but sometimes this is a combination of field inputs, or the model's relationship to other models that determine the valid state.

Your model should encapsulate this logic so you can interrogate it ("are you valid?") and not have it spread across other parts of your code.

回答2:

There is no single answer. What will begin to surface is that validation can not solely happen at the model because the model does not have knowledge of its surroundings. A prime example of this is duplicate names where uniqueness matters form a visual stance. The moment that requirement surfaces, some sort of validation is going to take place external to the model or the model is going to have to become aware of its surroundings which begins the coupling.

I try to push as much as possible into the model, that is relative to the model/requirements. Once it extends beyond that the only other place to go is within the controller.

回答3:

I agree on the fact there's no unique solution.

I tend to keep validation which is related to the logic of the application in the controller. This has a great advantage in those cases where the model can vary (otherwise you need to replicate the checks in all models).

In the model, I just keep validation which is dependent on the storage mechanism.

The view could be a good place to implement some client-side validation, for immediate feedback.

Again, this is just my opinion.

回答4:

Personally I validate in both the Controller as the Model, but I tend to stick to validation in the Controller only to be sure that a certain Model function should be loaded. So basically: validate in order to control.

Example: someone tries to update certain information posting a form to ?p=foo&bar=1&baz=2. In the Controller I'd check whether the values 1 and 2 are actual numbers and it's a valid request. Maybe even do a check to see whether the user has access to this particular info.

If this is the case, I call on the update function in the Model which will then validate all the posted form data. If not, it usually means the user isn't supposed to be there in the first place and it doesn't even reach the Model.

回答5:

I agree with Andrew. It's the model's job to take care of data validation. Of course you can validate wherever you want, but it's MVC best practice to do it inside the model.