[eluser]Colin Williams[/eluser]
There are many ways to look at it, and I have never come down on either side of the fence. Here's my best answer:
Validation is made up of essentially two operations. Defining rules, fields, and values, and then running the validation process and reacting to success and failure. One could argue that rules, fields and values are all tied to the data, so defining those belongs in the model. But the success/error handling is business logic that belongs in the controller. So, you could simply add get_field(), get_rules() get_values() methods to your models, which the controller obtains and passes in to the Validation class. That seems like the best way to split the process.
However, I've yet to encounter a situation where I have two controllers that process the same exact form for the same exact object. So, abstracting it out via the model has never seemed necessary, so I do it all in the controller. And remember, too, that validation and prepping are two different things. Your models should always be responsible for prepping data before insertion. That is to say, your model functions should be extremely flexible as to what they accept, which can make for more friendly API. (An example would be a tagging system. The model should accept a comma delimited string of tags that it then translates into an array that it can process and add to the database. No reason for the controller to do this.)
