I have a MVC application that receives an input from a form.
This is a login form so the only validation that is necessary is to check whether the input is non-empty.
Right now before I pass it to the model I validate it in the controller.
Is this a best practice or not? Does it belong to the model?
相关问题
- How to dynamically load partial view Via jquery aj
- Rails how to handle error and exceptions in model
- Laravel model returns “Undefined property: stdClas
- Name for a method that has only side effects
- Rails Models and unique combinations
相关文章
- 关于Asp.net Mvc Core重写Initialize方法的问题
- laravel create model from custom stub when using p
- Spring: controller inheritance using @Controller a
- Forward request from servlet to jsp
- Should client-server code be written in one “proje
- Algorithm for maximizing coverage of rectangular a
- superclass mismatch for class CommentsController (
- Disable action method from being called from the a
Validation must be in the Model
Only the model knows the "details" of the business. only the model knows which data is acceptable and which data is not. the controller just knows how to "use" the model.
for example: let's say we need the functionality of registering new users to our system.
The Model:
Now the controller/s job is to "use" the model
registerUser()
function without the knowledge of how the model is going to do the validation, or even what is considered "valid" or not!the Controller:
The class user
having an architecture like that will "free" the controllers completely from the details of the business logic -which is a good thing-.
Suppose we want to make another form of user registration somewhere else in the website (and we will have another controller allocated for it). now the other controller will use the same method of the model
registerUser()
.But if we distributed the validation logic between the controller and the model they will not be separated -which is bad and against MVC- meaning that every time you need to make new view and controller to register new user you must use the same old controller AND the model together. Moreover if the business logic is changed (we now accept teenagers in our sports club) you are going only to change the code in the model
registerUser()
function. the controllers code is still the same.Its business logic, so no, it doesn't belong in the model.
I don't think there's an official best practice limiting validation to any single part of the MVC pattern. For example, your view can (and should) do some up-front validation using Javascript. Your controller should also offer the same types of validation, as well as more business-logic related validation. The model can also offer forms of validation, i.e., setters not allowing null values.
There's an interesting discussion of this at joelonsoftware.
I have been thinking about this for a LONG time and after trying putting validation in both controllers and models.... finally I have come to the conclusion that for many of my applications... validation belongs in the model and not in the controller. Why? Because the same model could in the future be used by various other controller calls or APIs... and then I would have to repeat the validation process over and over again. That would violate DRY and lead to many errors. Plus philosophically its the model which interacts with the database ( or other persistent storage ) and thus is sort of a 'last call for alcohol' place to do this anyway.
So I do my get/post translation in the controller and then send raw data to the model for validation and processing. Of course I am often doing php/mysql web applications and if you are doing other things results may vary. I hope this helps someone.
Within the controller you have the ModelState property to which you can add validation errors to.
See this example on the MSDN.