Home » Php » Laravel 4 Model validation vs Controller validation

Laravel 4 Model validation vs Controller validation

Posted by: admin October 29, 2017 Leave a comment


It seems like official way to validate models in Laravel 4 is through Validator in Controller? Can somebody point out why is it so?

Wouldn’t it make more sense to implement validation in Model?


I prefer the Ardent package for making validation of models as smooth and minimal as possible. To me it makes more sense to have the validation rules in the model as well.

It will return false when $model->save() is called and validation fails, then you can get the error messages through $model->errors()->all() for example.


It does make sense to have validation in the models, but this validation should only be there to make sure you don’t save any corrupt data.

The Validator is in the Controller because it’s used to handle Input, and generate Output.
If you would do the validation in the Model then you either have to return false, and show the user the most random of error messages about invalid data.
You could also return some kine of array containing all the errors that are generated, but that’s something a Model shouldn’t do.
Or you could throw an Exception, which is something that should be done when a model tries to consume invalid data, but it kills the application, which is not the wanted solution for a form validator.

When doing the form validation in the Controller, you can do everything you want with the error messages, without changing the purpose of a Model.

And in your model you can do a validation to make sure you didn’t make a mistake, which will corrupt your database. Because if this happens the application should shut down.

So to put this in a real answer to your question:
Validation in the model makes sense to avoid corrupt data, but if you want to give feedback to the user about invalid input, it should be in the controller.


I wrestled with this for a while and settled on handling most of my validation in a validation service, based something along the lines of this. I can then have different validation rules based on the context.

As Nico mentions, validation in the model is good to avoid corrupt data, but I prefer thin controllers so I pass the functionality that would sit in controller into the service. This also has the benefit of being able to reuse the validation in different controllers/methods.


Why I prefer In-Model Validation: I’ve worked with both styles and each have pluses and minuses, but I prefer in-model validation. In our current app I don’t see in-controller validation as an option, since we’re altering our data in so many places (dedicated forms, inline edit, bulk edit, bulk upload, api, etc). I’ve never really worked with validation services (though they might be an option) but I personally like to keep logic as close to the model as possible, that way I know another developer won’t bypass it. I also don’t like adding lots of extra files on top of the MVC and basic Libraries folder because it just seems like more you have to think about organizing properly.

Issues with In-Model Validation: These are some things you need to consider to make In-Model work well. SOME OF THESE ARE ALREADY TAKEN INTO CONSIDERATION BY PLUGINS. I think other frameworks (CakePHP) already deal with these, but Laravel doesn’t really.

  1. Values that will be validated but not saved to the db (e.g.,
  2. Many to many or belongs to many
  3. Setting conditional defaults (not critical but
    might want to think about at the same time)
  4. Various form scenarios – sometimes you might need different validation
    depending upon which form submits it. The form reference can be a
    purgeable attribute for validation maybe?
  5. How will you get back error messages (all in-model validation plugins handle this for you)
  6. Different validation rulesets. Draft creation vs “real” creation. (Most handle this for you)

Ultimately, for simple applications that don’t have lots of ways of interacting with the model, I’d say controller validation may be simpler, other then that I prefer in-model.