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?
views:
208answers:
7The answer below claims otherwise. Please elaborate and explain why do you think so.
the_drow
2010-01-15 00:43:37
I would likely go the route darren outlined below. In which case, it would go in your service layer.Basically, think of it like this; is not allowing an empty string a constraint placed on you by the model? And its not a UI concern. So it must be a business concern; a user cannot log in with an empty username.
brian
2010-01-15 00:52:45
The above answer says it's business logic so it doesn't belong to the model. You are saying that it does right?I'm confused. Please elaborate and explain why do you think so.
the_drow
2010-01-15 00:43:03
I disagree. I would say: Business Logic -> Domain; User interface logic -> Controller; Validation -> Domain + UI (optional)
Martinho Fernandes
2010-01-15 00:45:24
@the_drow: I'm saying that business logic **doesn't** belong in the Model, it belongs in the Controller.
Alix Axel
2010-01-15 00:52:48
@Alix Axel: Yes but what I said is that 'unknown (google)'s answer says otherwise. Please explain why?
the_drow
2010-01-15 00:57:28
Let me clarify: By Domain I mean what is known as the Domain Model, Domain Layer or sometimes Business Logic Layer (http://martinfowler.com/eaaCatalog/domainModel.html).UI is the User Interface. MVC is a user interface architecture (http://martinfowler.com/eaaDev/uiArchs.html).What I said above is that business logic does not belong in the user interface but in the domain layer. Validation should be in the domain layer, but it can also be used in other layers, like the UI (probably in the Controller or the View in Js) to give fast feedback to the user.
Martinho Fernandes
2010-01-15 01:24:54
A:
Within the controller you have the ModelState property to which you can add validation errors to.
statenjason
2010-01-15 00:43:46
A:
Assuming your application is structured like:
- Model-View-Controller
- Service
- Persistence
- Model
The user input would come to your controller, and you would use services in the service layer to validate it.
darren
2010-01-15 00:43:56
More layers? What's the service layer? There is no database so there is no persistence per se, all the data is taken from another process and all the data is changed either from the UI or the process.
the_drow
2010-01-15 00:50:43
+2
A:
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.
Kaleb Brasee
2010-01-15 00:48:47
I assume there's some Javascript somewhere in the app? Unless this is an old-fashioned Web 1.0-style web app or framework.
Kaleb Brasee
2010-01-15 01:08:11
There is but I don't touch/code/handle it unless I really really really want to :)In this framework the View only creates and initializes the widgets and attaches them to the root widget. It can have validation functions in it though. So the view is the place for validating if the data non-empty but the model is for verifying that the inputted username and password are correct?
the_drow
2010-01-15 01:16:05
Also should the view call model functions? That couples them and it loses the whole point. So here's what the controller is doing right now: validating for non-empty values and passes it to the model. Should I make the view call the controller that will call the model authentication method and then return an answer to the controller that will return an answer in the view? That sounds like a major overhead.
the_drow
2010-01-15 01:48:52
+2
A:
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.
Larry Zoumas
2010-02-23 08:39:22