Certes il est pratique d’utiliser autant que possible des normes ou des design patterns, mais leurs évaluations restent de mise. Je rappelle qu’il est indispensable de procéder à une validation de toutes les saisies utilisateur par une validation coté serveur à minima (une validation seulement coté client ouvre la porte à de nombreux problèmes de sécurité lorsque des injections se retrouveront directement coté serveur : de nombreux développeurs sont habitués à lire le code avec les outils de développement intégrés aux navigateurs (Chrome, Firefox), et à modifier des données y compris normalement non éditables)
1.2. Specification goals Validating data is a common task that occurs throughout an application, from the presentation layer to the persistence layer. Often the same validation logic is implemented in each layer, proving to be time consuming and error-prone. To avoid duplication of these validations in each layer, developers often bundle validation logic directly into the domain model, cluttering domain classes with validation code that is, in fact, metadata about the class itself. This JSR defines a metadata model and API for JavaBean validation. The default metadata source is annotations, with the ability to override and extend the meta-data through the use of XML validation descriptors. The validation API developed by this JSR is not intended for use in any one tier or programming model. It is specifically not tied to either the web tier or the persistence tier, and is available for both server-side application programming, as well as rich client Swing application developers. This API is seen as a general extension to the JavaBeans object model, and as such is expected to be used as a core component in other specifications. Ease of use and flexibility have influenced the design of this specification.
Néanmoins est-ce vraiment fiable à tous les niveaux ?
ALTER TABLE t_containers ADD CONSTRAINT check_tct_types_enforcement
CHECK (
(ct_type = ‘MODEGED’ AND ct_media IN (‘MAIL’))
OR
(ct_type = ‘GROUP’ AND t_parent IS NULL )
) EXCEPTIONS INTO rejets;
Dans ce cas la JSR de validation ne fonctionne pas : elle n’est en effet pas capable de connaître les contraintes de schémas, et donc incapable de les évaluer afin de remonter un message. La validation sera partielle et il faudra compléter cela dans le code.
A noter : le problème existe également dans les tests automatiques puisque l’évaluation n’est réalisée qu’au
COMMIT, alors que les tests sont souvent réalisés en readonly, sans COMMIT.