Just how much validation should a model do?

[eluser]The Wizard[/eluser]
it seems a little bit weird to me. i don't see any meaning in putting the validation into the model.
my functions in the models, at least for very important things, always check for issues that might
be an error or a hack attempt. i also proof the logic very strictly so it should be OK if only an
array is passed from the controller containing the data.
its not that important to me


what i would point out to is the matchbox attempt i saw in the wiki and the forum.
it was quite interesting attempt to reduce the amount of work done.
maybe that would be of help to you?

[eluser]TheFuzzy0ne[/eluser]
Matchbox attempt? The only matchbox I can find is an HMVC extension.

Thanks for your comments.

[eluser]xwero[/eluser]
I like Nogdogs idea but the problem is it tied in with the form_validation class. What if you add callbacks?

The problem with validating in the models is that the methods then have two sorts of errors, validation and database. A way to deal with it is to catch the validation errors in the controller

Code:

$this->load->model('some_model');
$return = $this->some_model->method();
// $return is the database error check and they are handled here
if($this->form_validation->has_errors())
{
  // handle the validation errors here
}

This piece of code assumes the form_validation library is loaded before the model is loaded and a has_errors method is added.

My current plan of attack is to put a special validation model in between the model and the controller but the model is more a controller than a model. The intention was to keep the actual model and the controller as maintainable as possible but nowadays i'm starting to realize the validation model is too much. But i haven't found a replacement flow where i'm comfortable with.

[eluser]n0xie[/eluser]
In my point of view the models should be pretty 'stupid', which means the only thing they check for is errors that happened during processing of data (db failure, empty query, stuff like that). I usually have a public available errormsg which can be read from within a controller. Now if my model returns false I can still get debug info if I need to:

Code:

/* model mymodel*/
private $errormsg;

public function dostuff(){
  try {
    // try to do something
  } catch($err) {
    $this->setErrormsg = $err;
    return FALSE;
  }
}

/* controller */
$this->load->model('mymodel');
if(! $this->mymodel->dostuff()){
  // something went wrong what should we do?
  // we could log it:
  // pseudocode:
  $this->log->('error occured in $controller using $model and $function', $this->mymodel->getErrormsg());
  // we could alert an user:
  // pseudocode:
  $data['error'] = 'something went wrong';
  $this->load->view('someview',$data);
  // or any other sort of stuff we want to do in case stuff breaks
} else {
  // resume flow normally
}

Imho controllers control the flow of the application. If something fails, the controller should be responsible for handling this. Hence all my models return FALSE for any operation that failed, so the controller can decide what to do.

Following this logic, the controller should also be responsible for validating/sanitizing data. Although you'll end up with 'fatter' controllers, it makes sense to me to decide inside the controller for example, if an empty input field is really something that is important enough to call a validation error, or if I could just insert it as an empty field.

The only exception I have is I do check for parameters inside a model, following the design by contract principle, mostly to prevent myself from shooting myself in the foot if I screw up the order in which to add params. But I'd say that that is pretty basic stuff.

Just my 2cnt