Où dois-je gérer les exceptions, dans le BLL, DAL ou PL?

Question

Quel est le meilleur endroit pour gérer les exceptions? BLL, DAL ou PL?

Dois-je autoriser les méthodes du DAL et BLL à jeter les exceptions à la chaîne et laisser le PL les gérer? ou devrais-je les gérer au BLL?

par exemple

Si j'ai une méthode dans mon DAL que les questions « ExecuteNonQuery » et met à jour certains dossiers, et en raison de l'une ou plusieurs raisons, 0 lignes sont affectées. Maintenant, comment dois-je laisser mon PL savoir que si une exception a eu lieu ou il n'y avait vraiment aucune ligne ne correspond à la condition. Dois-je utiliser « attraper try » dans mon code PL et le faire savoir par une exception, ou devrais-je gérer l'exception au DAL et retourner un code spécial comme (-1) pour laisser Différencier PL entre la (exception) et (pas rows état zéro-à-dire les lignes affectées)?

Answer 1

Il est absurde de laisser une exception qui se jette dans la bulle DAL jusqu'à la PL - comment l'utilisateur censé réagir si ce ne pouvait être établie la connexion de base de données

Catch et gérer les exceptions au début, si vous pouvez les manipuler. Ne vous contentez pas de les avaler sans sortir un indice ou un message de journal -. Cela conduira à des difficultés graves et des bugs qui sont difficiles à suivre

Answer 2

Ceci est un énorme sujet avec beaucoup de controverses inutiles (les gens avec des voix donnant une mauvaise info!) Si vous êtes prêt à faire face à cela, suivez les conseils de s1mm0t, il est surtout agréable.

Toutefois, si vous voulez une réponse en un mot, les mettre dans le PL. Sérieux. Si vous pouvez vous en sortir avec elle mettre votre gestion des erreurs dans un gestionnaire d'exception globale (toutes les erreurs doivent se connecter et de donner un code pour rechercher le journal dans la production pour des raisons de sécurité (en particulier si web), mais donner les détails dos au cours du développement pour des raisons de rapidité).

Edit: (précisions) vous avez à traiter avec quelques erreurs partout - mais ce n'est pas une norme 'chaque fonction'. La plupart du temps laissez-les bulles à la PL et gérer l'erreur globale de .NET avec votre propre code: connectez la pile d'appel complet à partir de là par une routine commune qui est accessible à partir de tous les 3 couches par des gestionnaires d'événements (voir EDIT en bas de messages ). Cela signifie que vous pas ont try / catch saupoudré à travers tout votre code; sections seulement vous attendent et erreur et peuvent le manipuler là, ou des sections non-critiques, avec lequel vous vous connectez l'erreur et informer l'utilisateur de la fonctionnalité indisponible (ce qui est encore plus rare et des programmes super-fiable / critique)

En dehors de cela, lorsque vous travaillez avec des éléments de ressources limitées, je l'utilise souvent « en utilisant » mot-clé ou try / finally / essayer final sans la prise. pour le multithreading verrouillage / mutex / drapeaux de prévention de ré-entrée / etc. vous avez également besoin d'essayer / enfin dans les cas tous si votre programme fonctionne toujours (en particulier des applications stateful).

Si vous utilisez des exceptions de manière incorrecte (par exemple, en cas de non-bugs lorsque vous devez utiliser la fonctionnera avant de l'essayer déclaration ou le vérifier une opération suspecte IF), cette philosophie va se désagréger plus.

Une note de côté, dans le client épais applications surtout quand il y a la possibilité de perdre des quantités importantes ou l'entrée des utilisateurs, vous pouvez être mieux avec plus try / prises où vous essayez d'enregistrer les données (marqués comme non-yet- valide bien sûr).

EDIT: un autre besoin d'avoir au moins le dans la routine vous connecter PL - cela fonctionne différemment en fonction de la plate-forme. Une application que nous travaillons sur les actions de la BLL / DAL avec 3 versions PL: une version ASP.Net, une version WinForms, et une application console Version de test régression en mode batch. La routine de journalisation qui est appelée est en fait dans le BLL (DAL lance uniquement des erreurs ou gère totalement tout il obtient ou les re-lance). Cependant, cela soulève un événement qui est géré par le PL; sur le web, il le met dans le journal du serveur et ne affiche des messages d'erreur de style web (message amical pour la production); dans WinForms une fenêtre de message spécial apparaît avec des informations de support technique, etc., et enregistre l'erreur dans les coulisses (les développeurs peuvent faire quelque chose « secret » pour voir le plein d'infos). Et bien sûr, dans la version d'essai est un processus beaucoup plus simple mais différent aussi.
Je ne sais pas comment je l'ai fait dans le BLL, sauf pour le passage d'un paramètre « quelle plate-forme », mais étant donné qu'il ne comprend pas WinForms ou bibliothèques asp que l'exploitation forestière dépend, qui serait encore un truc.

Answer 3

La réponse courte est que cela dépend!

Vous ne devriez jamais gérer une exception si vous pouvez faire quelque chose d'utile. Le « quelque chose d'utile » dépend encore une fois de ce que vous faites. Vous pouvez enregistrer les détails de l'exception, bien que ce ne gère pas vraiment et vous devriez vraiment jeter à nouveau l'exception après l'exploitation forestière dans la plupart des circonstances. Vous pouvez envelopper l'exception dans une autre (peut-être sur mesure) exception afin d'ajouter plus d'informations à l'exception. Comme @mbeckish touches, vous pouvez essayer de récupérer de l'exception, en réitérant l'opération par exemple - vous devriez faire attention de ne pas recommencer à jamais cependant. Enfin (excusez le jeu de mots) que vous pouvez utiliser un bloc finally pour nettoyer toutes les ressources telles qu'une connexion DB ouverte. Qu'est-ce que vous choisissez de faire à l'exception influencera lorsque vous le manipulez. Il est probable qu'il n'y a pas beaucoup de choses utiles qui peuvent être faites avec de nombreuses exceptions autres que le rapport à l'utilisateur qu'une erreur est survenue dans ce cas, il serait plus acceptable pour gérer l'exception dans la couche d'interface utilisateur et signaler le problème à l'utilisateur (vous devriez probablement enregistrer l'exception aussi bien, encore vos couches).

En jetant des exceptions vous, vous ne devez jamais jeter des exceptions dans « exceptional'circumstances comme il y a une grande tête à jeter des exceptions. Dans votre exemple, vous suggérez que vous pensez peut-être de lancer une exception si aucun enregistrement sont mis à jour par votre opération. Est-ce vraiment exceptionnel? Une meilleure chose à faire dans cette situation serait de retourner le nombre d'enregistrements mis à jour - cela peut encore être une condition d'erreur qui doit être signalé à l'utilisateur, mais pas exceptionnel comme la commande d'échouer parce que le connecction à la DB a descendu.

Cette est un article raisonnable sur la gestion des exceptions mieux pratiques.

Answer 4

La couche qui sait ce qu'il faut faire des choses ensemble devrait être juste la couche qui gère l'exception. Par exemple, si vous décidez de gérer les erreurs de blocage par la requête un Retrying certain nombre de fois, alors vous pouvez construire que dans votre DAL. Si elle continue à échouer, alors vous voudrez peut-être laisser la bulle d'exception à la couche suivante, qui peut alors décider si elle sait comment gérer correctement cette exception.

Answer 5

Toutes les couches de votre application doivent gérer les exceptions gracefullly. Ceci est connu sous un corncern croix de coupe, car il apparaît dans toutes vos couches. Je belive que l'aide d'un cadre comme l'entreprise Exception bloc avec l'unité, vous finirez avec un meilleur code général. Jetez un oeil à ce poste

http://msdn.microsoft. com / fr-fr / bibliothèque / ff664698 (v = PandP.50) .aspx

Il faudra un certain temps pour le maîtriser, mais il y a beaucoup d'exemples et screencast autour de là.

Answer 6

Comment gérer les exceptions dépend des besoins techniques et commerciaux. Pour les mises à jour de bases de données complexes ou très importantes que je params les articles qui passent une petite liste des erreurs connues de sauvegarde à la DL. De cette façon, les scénarios d'erreur connus peut être résolu par programme dans certains cas. Dans d'autres cas, l'erreur doit être connecté et l'utilisateur doit être averti d'une erreur.

Je fais une pratique de la notification d'un être humain d'erreurs. Bien sûr, l'exploitation forestière nous donnera des informations détaillées, mais il ne peut remplacer le temps de réponse d'un être humain. Non seulement cela, mais pourquoi les développeurs de force de regarder les journaux système juste pour voir si les choses vont au sud? Parlez de coûts inutiles.

Si vous avez le temps de définir les erreurs potentielles / exceptions et de les résoudre par programme, puis par tous les moyens le faire. erreurs / exceptions sont inattendues nombreuses fois. Voilà pourquoi il est important d'être préparé pour cette inattendue et quelle meilleure façon de le faire que impliquant un être humain.

Dans l'ensemble, on devrait être sur la défensive lors de la planification de gestion des exceptions. Les programmes se développent ou ils meurent. Une partie de la croissance est l'introduction d'insectes. Alors ne faites pas tourner vos roues en essayant de les tuer tous.

Answer 7

La question vous est où est l'exception pertinente? Si elle est une exception d'accès aux données, il doit être pris dans le DAL. Si elle est une exception logique, il doit être pris dans le BLL. Si elle est une exception de présentation puis dans le PL.

Par exemple, si votre DAL lance une exception, il doit retourner une valeur nulle ou un faux ou quel que soit le cas à votre BLL. Votre BLL doit savoir quoi faire si le DAL retourne une valeur nulle, peut-être qu'il transmet à travers, peut-être qu'il essaie d'appeler une autre fonction, etc. La même chose avec votre PL si le BLL passe par un nul de la DAL ou retourne quelque chose de spécifique de son propre puis la couche de présentation devrait être en mesure d'informer l'utilisateur final qu'il y avait un problème.

Bien sûr, vous ne recevrez pas le bavard messages d'exception, mais qui est une bonne chose en ce qui concerne vos utilisateurs. Vous devriez avoir un système d'enregistrement flexible pour attraper ces exceptions et de les signaler à une base de données ou un IP: port ou tout ce que vous décidez.

Essentiellement, vous devez penser en termes de séparation des préoccupations si la préoccupation est une donnée question ou un problème de logique, il doit être traité en conséquence.