2009-05-11 8 views
0

Lors de l'enregistrement de données à l'aide d'une procédure stockée, nous rencontrons souvent des contraintes de clé étrangère, des contraintes de clé uniques, etc. Toutes ces erreurs peuvent être corrigées en transmettant les bonnes données.Validations de couches persistantes

La validation peut être effectuée dans la couche logique métier et ne doit être envoyée à la couche de persistance que si elle réussit. Mais dans certains cas, il est pratique de valider les données pendant l'enregistrement. Comme dans une procédure stockée.

Supposons par exemple que si l'utilisateur entre des valeurs de plage de dates, il doit être validé que la plage ne chevauche aucune plage existante. Dans une telle situation, il est préférable de renvoyer un code d'erreur qui peut nous indiquer si la plage se chevauche et ne peut pas être sauvegardée.

Dans SQL Server, nous pouvons simplement lever des exceptions personnalisées, mais je souhaite le faire sans utiliser d'exceptions. Y at-il des cadres de validation déjà disponibles que je peux utiliser. Je suis à la recherche d'une solution spécifique SQL Server 2005 et .net.


P.S .: Je retourne généralement des codes d'erreur personnalisés à partir des procédures stockées et les analyser en regardant dans un fichier xml, puis l'utiliser dans mon moteur de règles de la couche d'affaires.

Répondre

2

L'intégration de la logique métier dans SQL Server peut améliorer les performances, mais elle va compliquer la conception en violant la séparation des problèmes. Pour que ma logique métier soit portable, il faut que ce soit dans la couche métier. Je supprimerais la logique de validation des procs stockés et ne les utiliserais que pour faciliter les opérations CRUD. Vous ne savez jamais quand les parties prenantes du projet vont dire "faites-le fonctionner sur la base de données X!". Faites de votre mieux pour garder la base de données de la logique de validation indépendante.