Where is the best place to verify form data ?

Question

Question is simple . Where should I put form verification process in the mvc design pattern (Zend , Symphony, Cakephp, Codeigniter) . I ask this question because i have my own framework. But i can not decide where should i handle form verification . For example , i can write if statements in controller but this makes controller "fat" , or i can add verification statements in model function ( in User::register( , , ) ) . Of course this is not very complex thing ,but my aim is to understand how do they do in enterprise level applications .

Answer 1

If you consider the Models in MVC as what we in the .NET world call ViewModels (and I believe are called Presentation Models elsewhere) instead of Domain Models, the Model would be an excellent place to add validation/verification.

This would allow you to reuse the verification logic anywhere you are reusing the Model, and it makes sense since the Model would be encapsulating the verification logic together with the data. That sounds like high cohesion to me.

As a sanity check, the ASP.NET MVC framework seems to be heading in that direction as well. Since the question is tagged 'php' I'm not sure this last piece of information strengthens or weakens the argument.

Answer 2

Validation is Control of input. MVC stands for Model View Controller, so validation should be in a controller.

General validations like isInt(), isStr(), isEmailAddress, isFloat() etc etc could/should be placed in a base controller. Then you can have subcontrollers for specified Models (mapping to your database). Those subcontrollers then extend from the base controller.

Answer 3

There are multiple places where validation can happen.

First, client-side versus server-side: it's frequently a good practice to do pre-validation on the client side (ex. "only numbers allowed!") before sending the bits up the wire. Server side validation is always mandatory as a security / data integrity requirement.

Front end versus model requirements: a particular form might not know of model's requirement for related data objects (for example, if there's a business logic rule that value of 3 in a particular field should not be present if the number of related records is less than 5) - the only place that would know that is the model.