3 votes

Connexion passive dans une application Web .NET existante ?

Je viens de commencer à travailler sur une application Web ASP.NET 2.0. Comme c'est souvent le cas, l'architecture, et plus particulièrement l'architecture de journalisation des exceptions, est incohérente et, à certains endroits, manquante ou incorrecte (avaler les exceptions, les relancer, les utiliser pour la logique de contrôle, etc.)

Comme point de départ pour contrôler tout cela, j'aimerais simplement attraper TOUTES les exceptions lancées dans l'application, et les enregistrer quelque part, dans une table de la base de données par exemple. Malheureusement, coder explicitement cela dans l'application demanderait plusieurs jours et probablement des semaines de travail, ce qui exclut le codage manuel (par exemple, mettre logger.log(ex) partout) et des choses comme log4net et nlog. Ce que je cherche, c'est une autre solution, plus légère, au problème.

Après quelques lectures rapides sur ce site, j'ai découvert des techniques comme.. :

  • Programmation orientée aspect, comme
    • Basé sur les attributs
    • Bibliothèque de Post Sharp
    • Microsoft Unity
    • L'unité du château
  • Gestionnaires Web
    • ELMAH
    • D'autres ?

Quelles ont été les expériences des gens avec ces solutions ? Gardez à l'esprit que j'aimerais mettre en œuvre cette solution de la manière la plus simple et la moins pénible possible, et qu'il n'est donc pas nécessaire d'avoir recours à des gadgets à ce stade. Tout ce dont j'ai besoin, c'est d'une solution qui signale chaque exception à un seul endroit afin que je puisse commencer à trouver les trous dans la logique.

EDIT:

Je devrais probablement préciser que je veux consigner les exceptions de ****ALL**** (même celles qui sont traitées, car certaines sont traitées de manière incorrecte). Est-il possible de configurer Elmah pour faire cela ? Si non, quelles sont mes autres options ?

5voto

John Nolan Points 16633

Je recommande vivement l'intégration d'elmah dans votre application. C'est une révélation pour découvrir où les choses vont mal. J'ai eu plusieurs time-outs non signalés dans mon application par exemple, que j'ai identifiés et corrigés.

Quant à la simplicité et à l'absence de douleur. Cela n'implique aucune modification de votre code, si ce n'est quelques lignes supplémentaires dans votre web.config. Vous pouvez l'ajouter et afficher les exceptions en moins de 10 minutes.

3voto

John Saunders Points 118808

N'ajoutez pas de prises. Activez Surveillance de la santé d'ASP.NET . Si vous le souhaitez, vous pouvez le configurer pour qu'il se connecte à une base de données.

En dehors de ça, j'irais avec Bibliothèque d'entreprise Le bloc d'application des exceptions et le bloc d'application de la journalisation. Appliquez la journalisation où vous voulez (elle peut être désactivée en production), mais ne récupérez les exceptions qu'aux limites de la couche, par exemple dans vos méthodes DAL publiques.


L'un des avantages de la bibliothèque d'entreprise est que la Conception pour les opérations joue bien avec lui, si c'est le genre de chose qui vous intéresse :

Projet axé sur le développement d'outils et des conseils pour permettre le développement d'applications hautement administrables sur la plate-forme Windows.

Ce projet a permis de créer deux produits livrables. Le premier est le Visual Studio Team System Management Model Designer Power Tool (TSMMD). TSMMD est un outil de modélisation des scénarios de santé scénarios de santé et l'instrumentation l'instrumentation associée. L'outil comprend des paquets d'orientation qui génèrent l'instrumentation de la plate-forme (appelée Instrumentation Helpers) et des validateurs pour confirmer que le code source code source de l'application contient l'instrumentation définie dans le modèle de santé. L'outil peut ensuite être utilisé pour générer Management Packs pour System Center Operations Manager 2007. Enfin, le Guide de gestion qui contient des conseils prescriptifs sur la création d'applications hautement administrables sur la plate-forme Microsoft Windows.

1voto

Ryan Points 106

Envisagez l'utilisation d'un Aspect Oriented Framework pour injecter du code de journalisation dans votre source avant la compilation. La journalisation est l'application la plus classique de la POA, et la plupart des progiciels devraient donc être en mesure de répondre à vos besoins.

Voici une belle liste de bibliothèques AOP. http://www.bodden.de/tools/aop-dot-net/

J'ai joué avec la PIC dans .NET il y a environ 4 ans, il semble que les bibliothèques aient beaucoup évolué depuis.

0voto

Dima Points 1848

Si vous voulez éviter de toucher à la base de code existante, alors la POA, telle que mentionnée par d'autres, est la voie à suivre. Je ne sais pas comment cela fonctionne en .Net, mais j'essaie personnellement de rester à l'écart de ces technologies fantaisistes en Java, car elles vous font perdre le contrôle et entraînent une baisse des performances. Bien sûr, cela dépend de la nature de votre système. Quant à la gestion des journaux, essayez logFaces Il vous permettra d'accéder instantanément à toutes vos erreurs et vous épargnera bien des tracas dans la gestion des fichiers journaux. Un soin particulier est apporté aux traces de pile d'exception et à la corrélation du code source.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X