2009-07-16 8 views
1

Je voudrais savoir, dans un sens pratique, sur un projet à grande échelle (Java - mon cas) est-il préférable de coder simplement la logique défensive pour protéger contre les données invalides dans la BD ou simplement prendre le temps de passer Assurez-vous que vous n'acceptez aucune donnée invalide? Rappelez-vous, le problème ici est qu'il y a beaucoup de cas où une valeur nulle est correcte, et il y a beaucoup de cas où une valeur nulle n'est pas, donc le cas pour s'assurer qu'il n'y a pas de données invalides est non trivial. La raison pour laquelle je pose cette question est parce que je travaille sur un grand projet et que je me retrouve à courir après quelques mauvaises exceptions de pointeur nul pour me rendre compte que la raison pour laquelle il est lancé est obscure. Donc, je vais parler avec un ingénieur système seulement pour réaliser que dans la conception, cela est censé avoir été défini par un utilisateur, etc.Assurer des données valides ou protéger contre les données invalides? Tous les deux?

Remarque: ne pas attribuer ces problèmes à la simple "mauvaise conception des systèmes" . La question de savoir si le design aurait pu être meilleur n'est pas la question à résoudre (car tout design peut évidemment être amélioré). Je voudrais prendre cette forme comme un point de vue d'un développeur qui a déjà rejoint un projet très avancé (en termes de temps passé et de lignes de code) et ce qu'il devrait faire à partir de maintenant?

Merci!

** Il me vient à l'esprit que beaucoup pourraient considérer cela comme un problème opiniâtre? Si tel est le cas, n'importe qui peut se sentir libre d'en faire un wiki communautaire. Je ne suis pas sûr cependant. Il pourrait y avoir une convention ou une «bonne pratique» dont beaucoup ne sont pas au courant et qui, par la suite, ne serait pas du tout une question dogmatique, simplement pour m'informer, un nouveau développeur, de cette pratique.

Répondre

4

J'ai tendance à écrire mes objets pour valider lors de la construction (la plupart du temps mes objets sont immuables). Les setters vont aussi valider.

Les validations comprennent des vérifications nuls (la plus courante - j'essaie très difficile d'empêcher les valeurs nulles, et le code de commentaire lorsqu'une valeur nulle est autorisée), certaines vérifications de santé sur les valeurs. Ceux-ci se traduiront par IllegalArgumentExceptions en cas de défaillance (généralement)

Quand dois-je effectuer ces validations? Pas sur tous les objets/objets auxiliaires, etc. Généralement sur une sorte de transition entre les couches appropriées ou les ensembles de composants dans mon application. En règle générale, tout composant susceptible d'être réutilisé par un nouveau client effectuera une validation. Donc (dans votre exemple) la couche de base de données fournirait une validation, généralement indépendamment des autres couches (ce n'est pas déraisonnable si vous pensez que les différentes couches de l'application représentent les données sous différentes formes). sur la source de ces données. par exemple. les validations sont exécutées le plus rigoureusement sur l'entrée de l'utilisateur (par exemple les entrées dans les champs de texte, etc.). Je suis moins rigoureux pour vérifier les entrées qui proviendraient (disons) d'une configuration Spring XML.

La validation est extrêmement importante. Vous vérifiez vos données immédiatement, pas quand cela va causer un problème. Cela rend la vie beaucoup plus facile (imaginez si vous acceptez une mauvaise entrée, serialise l'objet, deserialise après un an, et trouvez que vous ne pouvez pas l'utiliser!)

1

Utilisation (NOT NULL, par exemple) les contraintes de base de donnéespour interdire les données invalides dans la base de données par n'importe quel moyen et entrer la validation dans votre code d'application Java pour interdire à l'utilisateur d'entrer des données invalides.

Les contraintes de base de données seules ne sont pas suffisantes car l'utilisateur doit voir des messages d'erreur de validation significatifs. Et la validation d'entrée seule n'est pas suffisante car les données dans la base de données doivent être dans un état valide même s'il y a des erreurs dans le code de validation d'entrée. De plus, les données de la base de données ne doivent pas nécessairement provenir de votre application.

0

Si l'utilisateur est supposé entrer des données dont la validité sera vérifiée ultérieurement, vous ne devez accepter aucune des données tant que l'utilisateur n'a pas rempli les champs requis. Cela n'a pas de sens d'accepter des données incomplètes et d'écrire des données incomplètes dans la base de données.

Toutefois, vous devez également vérifier les données lorsque vous les récupérez dans la base de données, avant de tenter de les utiliser ou de les transmettre à l'utilisateur. Peut-être que les données ont changé à partir d'une source externe, peut-être que les données sont juste corrompues, mais vous devez le vérifier.

Donc la vraie réponse est "les deux fois". Vous devez le vérifier aux deux extrémités.

Questions connexes