Meilleure approche pour partager des messages entre le niveau de données et le niveau application

Question

Je cherchais toute suggestion ou une bonne approche pour gérer les messages entre les niveaux de données application &, ce que je veux dire avec c'est lors de l'utilisation des procédures de stockage ou même en utilisant des instructions SQL directes dans l'application, il devrait y avoir un moyen pour que le niveau de données informe les couches supérieures des résultats de l'instruction/de l'opération d'une manière au moins organisée.

Ce que j'utilise couramment est deux variables dans chaque procédure de magasin:

@code INT, 
@message VARCHAR(1024) 

Je mets les déclarations DML dans un bloc TRY CATCH et à la fin du bloc d'essai, définissez les deux variables à un certain statut qui signifie tout se ok, comme vous pourriez penser que je fais le contraire sur le bloc de capture, réglez les deux variables à un code d'échec si nécessaire effectuer une gestion des erreurs.

Après le bloc TRY CATCH i retourner le résultat en utilisant un enregistrement:

SELECT @code AS code, @message AS message 

Ces deux variables sont utilisées dans les niveaux supérieurs à des fins de validation comme l'envoi de messages à l'utilisateur, également pour avoir commis o faire reculer les transactions.

Peut-être que je manque des fonctionnalités importantes comme RAISERROR ou ne pas imaginer des approches meilleures et plus optimales et sécurisées.

J'apprécierais vos conseils et bonnes pratiques, ne demandant pas de recettes de cuisine, il n'y a pas besoin, juste l'idée, mais si vous décidez d'inclure des exemples, ils seraient plus que bienvenus.

Merci

Answer 1

L'approche généralement acceptée pour résoudre ce problème consiste à demander à votre sproc de définir une valeur de retour et d'utiliser une erreur de relèvement comme cela a été suggéré précédemment.

La principale chose que je soupçonne que vous manquez est comment récupérer ces données sur le côté client.

Si vous êtes dans un environnement .net, vous pouvez vérifier la valeur de retour dans le cadre du code ado.net. Les messages d'erreur d'augmentation peuvent être capturés en attrapant l'objet SqlException et en itérant à travers la collection d'erreurs.

Vous pouvez également créer un gestionnaire d'événements et le joindre à l'événement InfoMessage de connexion. Cela vous permettra d'obtenir les messages tels qu'ils sont générés à partir du serveur SQL au lieu de l'achèvement du traitement par lots ou de la procédure stockée.

une autre option que je ne recommanderais pas, serait de suivre toutes les choses qui vous intéressent dans un message XML et de revenir à partir du processus stocké cela vous donne un peu plus de structure que votre approche de champ de texte libre.

Answer 2

Mon expérience a été de compter sur le fonctionnement des mécanismes inhérents de procédure. Ce que je veux dire par là, c'est que si une procédure doit échouer, soit l'erreur déclenchée implicite (si vous n'utilisez pas try/catch ... simplement des trucs CRUD) ou en utilisant le RAISERROR explicite. Cela signifie que si le code tombe dans le bloc catch et que je veux notifier l'application de l'erreur, je re-augmenterais l'erreur avec RAISERROR. Dans le passé, j'ai créé une procédure de relance personnalisée afin que je puisse piéger et consigner les informations d'erreur. On pourrait utiliser le rethrow comme une opportunité de lancer un message/code personnalisé qui pourrait être utilisé pour guider l'application sur un chemin de décision différent. Si l'application appelante ne reçoit pas d'erreur lors de l'exécution, il est raisonnable de supposer qu'elle a réussi - la validation de transaction explicite peut donc commencer.

Je n'ai jamais essayé d'écrire dans mon propre mécanisme de communication pour l'interaction entre l'application et le proc stocké - les objets dans les langues avec lesquelles j'interagis ont des événements ou mécanismes pour détecter l'erreur générée par la procédure. Il me semble que votre approche ne nécessite pas forcément beaucoup plus de code que la gestion des erreurs standard, mais je trouve cela déroutant car il semble réinventer le type de scénario. J'espère que je n'ai pas mal compris ce que vous faites, et que je ne veux pas non plus être critique; Je crois, cependant, que vous avez ce mécanisme de rétroaction disponible avec l'API standard et que cela rend probablement cela trop compliqué. Je recommande de lire sur RAISERROR et de voir si cela va répondre à vos besoins (voir aussi le lien Utiliser RAISERROR pour cela au bas de la page).