Question

Tout d’abord, nous nous excusons pour le titre à consonance subjective. Ceci est conçu comme une question directe.

Je travaille actuellement sur une suite d'outils:

  • Un service Windows C #, destiné principalement à maintenir une base de données Oracle.
  • Un service Windows C # (qui sera utilisé sur plusieurs sites de nœuds) pour traiter le contenu de la base de données.
  • Une interface Web ASP.NET pour faciliter la gestion de l'ensemble "système"

Actuellement, les services Windows ont été développés en tant qu’applications de la console (pour faciliter le débogage / le développement) et je suis en train de les convertir en services. Après quelques jours de test avec ces services, je constate que je voudrais augmenter la granularité de mon enregistrement. Je constate que Console.WriteLine () me manque et je voudrais fournir une source de journal alternative, telle qu'un fichier à plat pour ce type de sortie. Cela m'a amené à penser: "Devrais-je utiliser un cadre ou en ai-je assez?"

La raison pour laquelle j'ai mentionné les aspects que je développe est pour éclairer ma situation. Un " noyau " Une DLL a été créée, commune à tous les composants, faisant la synthèse de la couche d’interaction entre les applications et la base de données. C’est dans cette DLL qu’une classe a été créée pour tenter de "se connecter à une table de la base de données". sinon en cas d'échec "se connecter au journal des événements local". Ça y est, c'est le degré de journalisation.

Dans les outils susmentionnés, il existe plusieurs instances de journalisation identiques à:

Log.LogError("Code", e.Message + "\n" + e.StackTrace);

Bien qu'assez simple, cette méthode utilise la réflexion pour identifier la source de l'erreur.

Ma question

En regardant ma solution de journalisation actuelle, il apparaît "suffisant". en termes de ce qu'il fait et comment il est intégré avec toutes mes solutions. Cependant, je me suis penché sur les frameworks de journalisation (notament log4net) et leurs fonctionnalités m'impressionnent. La possibilité d'ajouter ultérieurement, si nécessaire, un autre format de sortie (tel qu'un serveur SMTP) me semble plutôt cool! :)

Ce que je voudrais savoir, ce sont les avantages de passer à un framework (comme Log4net). Dans quelle mesure devrai-je adapter mon code? Est-ce que je regarde ou non l'herbe verte de l'autre côté? Et enfin, mais probablement le plus important, est-ce que je fais la bonne chose? Devrais-je simplement ajouter la possibilité à ma classe Log à & Log; LogDebug " et en finir avec ça? La dernière chose que je voudrais faire est de refondre complètement ma suite, juste pour un "basique" fonctionnalité, mais s’il ya d’autres avantages (conception, fiabilité, bonnes pratiques? etc.), je suis intéressé.

Merci,

Était-ce utile?

La solution

Une bonne journalisation est particulièrement bénéfique lors de l’exécution de code sur plusieurs systèmes distants. Pour autant que je sache, log4net vous permettra d’envoyer vos journaux à un serveur syslog distant sans trop de temps de codage (vous pouvez ainsi afficher vos journaux à partir de toutes les machines d’un seul ordinateur). centralisé), ce qui réduira considérablement le temps nécessaire pour obtenir des informations relatives à un bogue ou à un problème avec le système, et devrait également vous donner une indication de la prévalence du problème.

Comme mentionné dans d’autres publications, log4net autorise également plusieurs appenders et plusieurs niveaux de journalisation, ce qui vous permet de déterminer où vous souhaitez obtenir certaines informations de journalisation (dans une base de données ou dans un fichier plat local). Log4net vous permet même de vous déconnecter via telnet. ) à stocker est un gage absolu.

En ce qui concerne sa mise en œuvre, plusieurs bons sites vous expliquent la configuration. La façon dont vous utilisez réellement les objets de journalisation que vous donne log4net est un choix architectural, mais vous pouvez simplement changer le constructeur d'un objet pour prendre un objet log4net et à partir de cet objet, utilisez simplement l'objet log4net comme vous le feriez Console.WriteLine .

Je trouve la série de tutoriels ici sont particulièrement utiles, et vous en apprendrez plus sur les avantages et les différentes façons de configurer log4net.

Autres conseils

Oui. Utiliser une infrastructure de journalisation éprouvée (telle que Log4net) est une bonne idée.

Log4Net est configurable au moment de l’exécution (excellent pour détecter les problèmes dans le code de production).

Comme l'a souligné un intervenant, son utilisation est également très simple.

Oui, vous souhaitez absolument utiliser un cadre de journalisation. Un cadre de journalisation vous permettra de:

      
  • Définissez les niveaux de journalisation pour les différentes instances de consignateur.
  •   
  • Définissez les "appenders" " ou sortie pour chacune des différentes instances de consignateur.

Peut-être, plus important encore, si vous utilisez un cadre de journalisation, il est très facile d’échanger une implémentation du cadre de journalisation pour une autre (peut-être une implémentation nulle qui ignore simplement les messages); tandis que, si vous écrivez toutes vos instructions de journalisation, directement, échanger la mise en oeuvre sera un cauchemar.

Je pense que vous devriez utiliser Log4net, tout simplement parce qu'il est toujours préférable de le réutiliser que de créer son propre matériel. log4net a été utilisé par beaucoup de développeurs et est assez mûr.

Pensez à votre perspective de maintenance; Dans un ou deux mois, vous devrez peut-être modifier un peu votre classe de journalisation personnalisée, ajouter un support multithreading, etc. Et lorsque vous corrigez les bugs survenus dans votre classe de journalisation, vous allez manquer Log4net.

L’un des plus gros avantages est de ne pas avoir à gérer le code vous-même. La plupart du temps, les frameworks de journalisation ont beaucoup plus de fonctionnalités que votre propre solution. Parce qu'ils sont tellement axés sur la journalisation, ces frameworks sont généralement assez complets en termes de fonctionnalités et de manières de les implémenter. Et puis il y a la fiabilité; Il n'y a rien de pire qu'un framework de journalisation qui n'enregistre rien car il est buggé. ;)

Prenez, par exemple, ELMAH pour les applications ASP.net. Il inclut également des notifications, des exportations vers différents formats cibles, etc. Ce qui est très pratique mais que vous ne construirez jamais vous-même à moins d'en avoir vraiment besoin.

Le nombre de modifications à apporter à votre code dépend évidemment de votre code et du cadre de choix. Il est difficile de dire quoi que ce soit à ce sujet.

Je vais lancer un appel à NLog ( http://nlog-project.org/home ) car il ne souffre pas du syndrome 'Straight Java Port - then rewrite' de la plupart des bibliothèques .Net.

Parmi les principaux avantages pour nous, citons le très rapide Logger.IsFooEnabled (lecture volatile) et les performances globales du système.

A chacun son cas, mais je préfère personnellement NLog pour mes projets (et certains de mes clients aussi).

Salut, Florian

L’avantage d’utiliser un bon framework de journalisation tel que Log4Net est qu’ils ont peu d’impact sur votre code en termes de lignes de code que vous devez modifier (en d’autres termes, vous ne devez modifier que chaque ligne de journalisation existante).

De même, si vous souhaitez modifier votre code si vous changez de framework, ou si vous souhaitez le faire vous-même, vous pouvez toujours créer votre propre interface pour un framework de journalisation . Ensuite, il vous suffit de changer votre code en un seul endroit après cela.

Je pense que les administrateurs système s'attendent à ce que les services se connectent au journal des événements de l'application dans Windows.

Recherchez System.Diagnostics.EventLog, même si log4net y écrira également.

La déclaration initiale du le site Web log4j pourrait vous aider dans certains cas. questions, les principes sous-jacents sont les mêmes de log4net:

  

Avec log4j, il est possible d'activer   se connecter au moment de l'exécution sans modifier   le binaire de l'application. Le log4j   le paquet est conçu pour que ces   les déclarations peuvent rester dans le code envoyé   sans encourir une lourde performance   Coût. Le comportement de journalisation peut être   contrôlé en modifiant une configuration   fichier, sans toucher l'application   binaire.

     

En utilisant une hiérarchie de loggers, c’est   possible de contrôler quel journal   les déclarations sont générées arbitrairement   granularité fine mais aussi grande facilité.   Cela aide à réduire le volume de journal   sortie et minimiser le coût de   enregistrement.

Dans ce cas, il n’est clairement pas nécessaire de réinventer la roue. La plupart des frameworks de journalisation sont assez simples, donc l'ampleur des modifications dépendra probablement de la taille de vos programmes existants.

si vous écrivez correctement votre classe de consignateurs, elle sera facilement utilisable. Tout framework peut vous impressionner avec de nombreuses fonctionnalités, mais un autre framework est une autre variable de votre processus de débogage, car il peut vous donner une erreur inexistante ou faire une erreur seul en combinaison avec votre application. Si vous êtes prêt à effectuer des tests bêta pour un projet de logiciel open source, c'est très bien ...

À votre place, j'écrirais une classe de journalisation avec la possibilité d'étendre les fonctionnalités que vous jugeriez intéressantes pour votre projet en vous basant sur la liste des fonctionnalités que possèdent les frameworks connus. Je ne vois pas de problème à consigner quelque chose dans un fichier puis à l'envoyer par smpt. Une seule petite fonction suffit.

De plus, vous pouvez écrire votre propre classe qui sera assez abstraite et y insérer votre code de base. Si jamais vous deviez utiliser un framework externe pour tester votre classe, vous pourriez l’utiliser avec un impact minimal sur le code. Il suffit de regarder comment ces frameworks sont implémentés au niveau du code.

Pensez à cela, vous devrez apprendre à utiliser correctement ces frameworks lorsque vous n’avez pour l’instant qu’à enregistrer une toute petite partie de celle-ci ...

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top