Where to keep validation logic

OK i have seen other posts about this but none really specifically answer my question.

Where in an application should validation logic be?

I have a small application that allows new products to be instered into an applications database. There are different products with different fields i.e. product name, order number, description etc. New products can be inserted and existing products can be updated. Therefore when a new product is being inserted then all fields must be validated but when an existing product is being updated then only the fields being updated need to be validated i.e. maybe just the descirption is being updated so only that field should be validated.

Im thi开发者_开发技巧nking of an abstract class and two concrete classes for full and part product validators, each having their own validation logic contained at class level.

I have the feeling though that there must be a better pattern for this - any advice?

Assuming that you are using the MVC pattern for your project, validation logic would belong in the model. If you are working on an n-tier project, put the validation logic in your business layer and make sure that no entities can be written without previous validation.

But I would always validate the entire object. Sorting out what has been changed and validating only that seems like overkill. Unless of course you know exactly (by measuring) that this is going to be a performance issue.

Where in an application should validation logic be?

Depends on your architecture. Validation can be handled in multiple stages to achieve responsiveness. Typically, though the model/controller seems like a good place in a given MVC architecture. This question came up sometime back on Joel's old forum in context of the MVC architecture. It seems plausible that the model should be responsible for accepting/rejecting input.

Therefore when a new product is being inserted then all fields must be validated

Yes.

but when an existing product is being updated then only the fields being updated need to be validated i.e. maybe just the descirption is being updated so only that field should be validated.

You cannot possibly foretell which exact part will be updated. So, you'll need to write validators for all fields (columns of your database).

You could simplify life and have a single validator class (unless of course validating a particular set of attributes is too complicated/time consuming).

There are several places where you can and should do validation, because there are different levels of validity:

1. On the client side, fields that are required can be checked upon tabbing off of a UI control; strings that need to match regular expressions such as "yyyy-MM-dd" for dates should be checked. On web UIs, this is usually done using JavaScript.
2. On the server side, objects should be checked for validity as input parameters are bound.
3. Objects that are valid still have to be checked for "business validity" when processed (e.g., "a valid credit card number is required when paying by credit card").

You should do both client and server side validation. Binding and validation is done by your service tier when input is bound to objects. They also check against business rules when processing to fulfill a use case.