When should I validate in controllers and not in models?

Author: fREW Schmidt

16 Jun

I’ve been told numerous times by people that I believe are smarter than me that I should do validation in my controllers and not my models. mst said that some validation, like low level primary key type stuff, can be in models, because it has to be. But if I recall correctly almost everyone was against validating things like email addresses in my models.

I just read this article and a lot of what alias says seems to make good sense to me. But if what he says is true that means it would be best if I validated as much as possible in my model, and then bubbled up any errors to the controller via exceptions or something like that. That would also make it simpler for me to generalize things that need to be a certain type value on creation, but should never change after creation.

So tell me, dear internet, why shouldn’t I validate as much as possible in my models?

Filed under: Uncategorized

6 Responses for "When should I validate in controllers and not in models?"

Moritz Onken June 16th, 2009 at 10:59 pm 1
Because the model is not aware of the current user.
Depending on her locale the format of Date/Time inputs is different. Depending on his roles, he may or may not set or change columns.
Zbigniew Lukasiak June 17th, 2009 at 1:40 am 2
Important part of the problem are the error messages, for the display you need different messages than for the back end. I guess you could have a dictionary to translate them (and that would also be a good start for i18n) – but that’s additional complication. I think the advice to have model side validation is a good one – but it needs a lot of infrastructure to make it usable.
Dave Sherohman June 17th, 2009 at 3:47 am 3
I’ve seen a lot of people using different definitions of what’s a “model” and what’s a “controller”, so this could just be a terminology mismatch.

As I use the terms, in the context of a web app, the “model” includes all of the underlying business classes and the “controller” is responsible solely for mapping data from the model into the view (templates) to generate a page. Under that usage, then, yes, all validation is the model’s job.

To someone else, though, the “model” may only be the database (and perhaps a thin OO layer around it), while the classes encapsulating business rules fall into their definition of “controller”. By those definitions, validation clearly falls into the controller’s realm. (If you’re using Catalyst with “model” classes that have been auto-generated by DBIC from your database schema without having added methods to them that go beyond simple database pass-through accessors, then you’re probably using these definitions.)

What really matters is that you know where your invariant rules and logic – the things which would apply to all applications in the system if you were to write more than one – live. All non-application-specific validation should go there also, regardless of whether you call it a “model” or a “controller”.
David E. Wheeler June 17th, 2009 at 8:04 am 4
Because you should do validation in the database. This is one of the primary things a relational database is designed to do, so take advantage of it!

Theory
Amiri June 17th, 2009 at 2:35 pm 5
An email address seems like something that could easily go in the model, and should. The “earlier” it is handled, the better. I guess there are types of validation where the line gets more fuzzy.
Why you should validate in your controllers and not your models | A Foolish Manifesto June 17th, 2009 at 9:29 pm 6
[...] I got some responses based on my question yesterday about why validation shouldn’t be in the model of an MVC-based [...]