Quand dois-je besoin de plus d'un TraceSource dans le code?

Question

Si une application est en train d'écrire toutes ses données d'activité dans un fichier journal, est-il utile d'avoir plus d'un TraceSource? Je suis juste curieux de connaître les utilisations des cas où l'on aura besoin de plus d'un TraceSource dans le code.

Answer 1

Voir ces réponses à d'autres questions pour un bon point de départ sur l'utilisation TraceSources:

ne peut pas comprendre .net 2010 et le traçage app.config

Comment utiliser TraceSource dans toutes les classes

Je dirais que chaque fois que vous avez plus d'une classe que vous pourriez (pourrait) envisager d'avoir plus d'un TraceSource.

L'un des avantages d'avoir plus d'un TraceSource est qu'il augmente la granularité à laquelle vous pouvez contrôler votre exploitation forestière. Par exemple, si vous utilisez un TraceSource différent dans chaque classe, vous pouvez contrôler l'enregistrement vers le bas au niveau de la classe. Vous pouvez activer un (ou plusieurs) classes spécifiques et désactiver toutes les autres.

Ceci est un modèle commun pour les utilisateurs de NLog et log4net. initialisation typique des classes utilisant ces plates-formes d'exploitation forestière ressemblera à quelque chose comme ceci:

public class A
{
  //NLog example
  private static Logger logger = LogManager.GetCurrentClassLogger();

  public F()
  {
    logger.Info("Inside F");
  }
}

Dans cet exemple, l'enregistreur pour une classe est nommé pour le nom complet de la classe (NLog fait le travail dur dans GetCurrentClassLogger ()).

Pour faire quelque chose de similaire avec TraceSource, vous feriez quelque chose comme ceci:

public class A
{
  private static TraceSource ts = new TraceSource(System.Reflection.GetCurrentMethod().DeclaringType.ToString();

  public F()
  {
    ts.Information("Inside F");
  }
}

Si vous avez fait cela dans toutes les classes, vous pouvez contrôler facilement vous connecter par classe.

Je ne suis pas sûr que ce modèle est aussi commun avec TraceSource comme il est avec log4net et NLog. Je pense que vous pourriez voir plus souvent les utilisateurs de TraceSource obtiennent leurs TraceSources par domaine fonctionnel.

Ainsi, vous pouvez diviser votre application vers le haut dans « Lire », « Process » et « Write » fonctionnalité (ou tout ce qui fait sens pour vous). Dans ce cas, vous pouvez obtenir le TraceSource approprié dans vos classes en fonction de la zone fonctionnelle dans laquelle ils sont utilisés:

public class FileReader
{
  private static TraceSource ts = new TraceSource("Read");

  public F()
  {
    ts.Information("Hello from FileReader.F");
  }
}

public class NetworkReader
{
  private static TraceSource ts = new TraceSource("Read");

  public F()
  {
    ts.Information("Hello from NetworkReader.F");
  }
}

Et ainsi de suite.

Maintenant, vous pouvez activer la journalisation pour « Lire », et en dehors de tous les autres domaines fonctionnels (ou activer la journalisation pour verbeux « Lire » et moins bavard journalisation pour tous les autres).

En outre, l'une des options avec TraceListeners est sortie le nom TraceSource. Donc, dans votre sortie, il sera plus facile de comprendre votre exploitation forestière parce que vous pouvez, si vous choisissez de le faire, trouver relativement facilement tous les messages de journalisation qui sont générés à partir d'une zone fonctionnelle particulière (ou par un TraceSource particulier).

Si vous avez une bonne convention de nommage de l'espace de noms, vous pourriez même envisager d'obtenir la TraceSource pour chaque classe basée sur un nœud dans la hiérarchie d'espace de noms ou même basée sur l'assemblage que la vie de la classe. Il y a des appels .NET pour un type qui récupérera cette information pour vous.

Puisque vous regardez TraceSources, je vous encourage à regarder ce projet à CodePlex:

http://ukadcdiagnostics.codeplex.com/

Il est un projet agréable (basé sur TraceSource) qui vous permet de formater votre sortie de l'enregistrement d'une manière similaire à ce que vous pouvez faire avec log4net et NLog.

Je vous encourage à jeter un oeil à cette enveloppe de l'exploitation forestière construit autour TraceSource du château.

https: / /github.com/castleproject/Castle.Core/blob/master/src/Castle.Core/Core/Logging/TraceLogger.cs

La chose intéressante qu'ils ont fait est de fournir une hiérarchie aux noms TraceSource. Je l'ai mis en place quelque chose de similaire dans le passé. Il fonctionne assez bien.

Ma réponse à cette question donne une idée de la façon dont une hiérarchie TraceSource peut être bénéfique:

Quelle est la meilleure approche pour l'exploitation forestière?

Bonne chance!