Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should you validate in the Model? (Symfony based question, but related to general MVC)

This is a quick question relating to Symfony, but could be a general MVC question.

I have a class in my model, for example, WebUser. This class has a property of email_address. This value must be unique to each WebUser.

Now, I've made it so all my Symfony forms validate that the email_address is unique for the given WebUser, however I'm wondering if I should add this validation to the model as well?

But this also got me thinking, should you actually validate every set() method in the model? It seems a wise enough decision to make sure no erroneous data ends up in the database, however most (if not all) data has to go through the controllers, which validate as well. So to me it seems I'm running the same validation twice and it just seems pointless?

What are your thoughts on this? I'm still leaning towards validation in the model as that makes the most sense as it dictates the business logic.

If you should validate in the model, how do you throw an appropriate set() error in Symfony that is handled correctly by the form framework?

Thanks.

like image 643
Stephen Melrose Avatar asked Jan 25 '10 13:01

Stephen Melrose


2 Answers

I can't speak specifically to Symfony, but I know that I purposely shun Zend Framework's form validation, and instead validate on my models (Zend Framework does not provide its own Model component, so it has no actual opinion on the matter).

There's nothing wrong with validating on the form, but I think you should also be validating on the model. Validating on the form might be useful for quick and easy input checking, especially if the processing logic is complex - you won't waste time working with data that's obviously bad.

Reasons I think model validation is best:

  • There's a chance a model will alter the data after it passes through the form and before it goes into the DB
  • Validation should be part of domain logic, not front-end logic (I realize Symfony seems to disagree).
  • Validation state travels with the model object, instead of the form object.

If you're not totally sold validating only in the model, a combination of the two sounds like a good solution.

EDIT: At the end of the day, it might make the most sense to just go with your framework on this. If Symfony seems most opinionated toward validation in the controller, and doesn't provide an easy path for validation in the model, just go with what they want you to do (or the direction in which the Symfony community leans). Fighting your framework is never fun.

like image 43
Bryan M. Avatar answered Sep 28 '22 01:09

Bryan M.


I disagree with "Validation should be part of domain logic, not front-end logic".

Validation is a complex functional part of your application and must be context aware. ie. you have to know is the user is logged in, what kind of credentials she has, the status of the request/form and so on. Models instead must be context agnostic (to work in any environment not only http request but also cli etc.) so they don't know about the user, the state and the http request. This is a strong requirement for the testability of your model classes.

For the summentioned reason functional validation must belong to the form which knows the application state (ie. session). symfony helps a lot with the sfValidator* classes which belongs to the form component indeed. That's the reason why forms are tested with functional testing.

Data validation should be in the model instead (ie. check if the value is an integer or a string, check if it's null and so on). This is easily accomplished with the Doctrine in-schema validation rules.

like image 176
gpilotino Avatar answered Sep 28 '22 01:09

gpilotino