views:

70

answers:

4

Let say I devise an architecture like this - an application consists of modules and modules uses domain-specific utilities to perform changes to the model or database.

An example, a registration module which shows the form, accept input and then use a registration utility which will perform the calls to insert the user info do the DB. Who is responsible for performing data validation?

1) The module, as it is the 'superior' passing data down to an utility 2) The utility, this way no suspect data would ever get through 3) Both should have thorough data validation 4) Some other arrangements

Thoughts? Opinions?

A: 

Validation should be as closer to the model as possible. Since the utility changes the model it should not trust the validity of the data module sends it. This way it's safer to reuse the utility (you can use it in more then one module without copying the validation code).

On the other hand, placing the validation on the module - which is closer to the user gives better experience (faster - client side validation etc.). So, in my opinion, the best way is to put the validation in your utility and later, if you have resources enhance user experience by adding another layer of validation in module.

Senad Uka
+1  A: 

Data should be validated as soon as possible - ie, there should be the minimum amount of distance between when data is read from input (such as user input) and when it is validated. The practical reason for this is it makes it easier to review the validation code.

In MVC, I would say it should go into the 'controller', assuming that the controller is where you read in all the input values (the controller then passes the validated values to the model, when you do it this way).

That said, there will likely be a fair bit of stuff in your validation code that can be shared, and you can write yourself helper code for validation.

thomasrutter
+4  A: 

Any component that is using data is responsible for validating the data for its own purpose.

For example: Some part of a service layer may validate that an input field is a valid email address, because that's what the business rules dictate. While the data layer may validate that the data is no longer than a particular length, because that is the largest that can fit in the database column, but it doesn't particularly care if it's an email address or not.

It should also be in a location that allows re-use. So (in MVC) the "valid email" validation from above wouldn't go into a controller or view because input into that piece of business logic is likely to happen in more than one controller/view, and this would require the duplication of the validation logic.

Brenton Alker
A: 

The place for validation depends on the API exposure inside the application and where in the design the validation should occur (i.e. who owns the validation concern).

For setting a valid email address, the controller accepting the data should probably do that because all the other code will be expecting a valid-looking email address. On the other hand, validation that the data is properly escaped for database handling belongs way down deep inside the model, just above the actual SQL handling.

staticsan