One can think of two kind of applications :
* Self-Service - Self-Service applications addresses the general case of internal and external users interacting with enterprise transactions and data.
* Extended Enterprise - Extended Enterprise applications addresses the interactions and collaborations between business processes in separate enterprises.
One can think of two kind of validations :
* Client facing validation addresses form - or field-level validation
* Business facing validation addresses the enterpise level business rules
We are going to implement some kind of validation on the client(WebApp). i think it should be implemented in the client logic, and let the DTO to be really simple and plane. Do you agree?
Some rules I would apply :
* Extract the common validation logic in a separate module and apply that to your DTO.
* Implement specific client facing validation logic in the DTO.
* Implement the busines specific rules in the business layer.
If you are facing serious performance penalties because of this approach. Also implement client facing validation logic in javascript.
Also i think that is mandatory strong validation at server lever ... mainly because we could use another client, or a 3rd party could implement their own (insecure) client,
... so where to place it?! ... it could be at business layer, near the app facade ... or/and in the model entities.
Maybe it could be everywhere ... in the client, in the business, in the model ... but ... have validation code in all layers it seems difficult to maintain
I would make a classification of different type of common and more specialized validation logic.
Based on the rules specified above. Also realize web application tend to move from Self Service type of applications to Extended Enterprise type of applications.
If most of validation logic and business rules are implemented in the web tier of your application. You would face the consequences of not being able to maintain, extend and scale your solution.
