ECRITURE DE LOG C# MULTI-THREAD ET MULTI-PROCESS

Signaler
Messages postés
108
Date d'inscription
vendredi 24 janvier 2003
Statut
Membre
Dernière intervention
10 août 2007
-
Messages postés
2
Date d'inscription
jeudi 26 juillet 2007
Statut
Membre
Dernière intervention
19 août 2015
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/43210-ecriture-de-log-c-multi-thread-et-multi-process

Messages postés
2
Date d'inscription
jeudi 26 juillet 2007
Statut
Membre
Dernière intervention
19 août 2015

Très utile, m'a fait gagner un temps précieux. Merci!
Messages postés
29
Date d'inscription
mardi 7 janvier 2003
Statut
Membre
Dernière intervention
26 mars 2009

Je trouve l'idée très bonne.

Simplement un commentaire:
Au lieu de définir une variable statique globale, tu peux créer un Singleton qui n'oblige pas l'instanciation à se faire dans le Main et n'oblige pas la déclaration Static.
La méthode getInstance() du Singleton peut renvoyer une interface ILog qui propose la méthode Write() principalement.

Donc, si tu fais Log.GetInstance().Write("mon info"); , cela écrira disons par défaut dans la sortie standard d'erreur, sans rien paramétrer avant.
La classe se suffit à elle même : déclaration, initialisation par défaut.

Un avantage est que le Singleton pourrait très bien dans le futur lire ses paramètres dans un fichier de configuration externe, qui pourrait contenir le nom du fichier par défaut, la chaîne de connexion BDD, etc. Ce qui n'oblige pas l'application en cours à paramétrer le type de Log désiré.
Rien n'empêche d'exposer des méthodes qui permettent de paramétrer depuis le Main() en plus, comme tu le fais actuellement.

Un autre avantage est que tu peux faire ta cuisine interne dans le Singleton : tu peux instancier une classe qui implémente ILog, et donc déporter la méthode Write() dans d'autres classes : "class LogWriterToFile : ILog", ou LogWriterToDefaultOutput, LogWriterToDB, etc... et dans la méthode Write() de la classe Log, tu peux appeler :

// --- Singleton (constructeur privé...)
class Log : ILog
{

// -- Par défaut sortie standard
private _writer = new LogWriterToDefaultOutput();

(...)

public ILog GetInstance()
{

}

public void Write(...)
{
_writer.Write(...);
}

}

A mon sens cette approche permet également beaucoup de souplesse : possibilité de chaîner les appels, d'utiliser le Design Pattern Proxy, le Design Pattern "chaîne de responsabilité" (si l'on admet qu'une info de succès doit être à l'écran, une erreur dans un fichier, et une info critique à la fois dans un fichier et envoyée par mail)...

Le Singleton peut aussi stocker une liste de ILog à appeler dans la méthode Write...

Le message c'est juste que travailler avec Singleton + interface autorise toutes les modifications de structure dans la façon dont le Log est géré derrière.
- Le Singleton sert de façade et d'accesseur global
- L'interface sert à pouvoir implémenter librement le code où l'on veut.

Enfin c'est un avis personnel.
Messages postés
1
Date d'inscription
samedi 6 octobre 2007
Statut
Membre
Dernière intervention
22 avril 2009

C'est sympa comme code.
Une remarque quand même.
Quand il y a des chaines multiples à concaténer, il est préférable d'utiliser la méthode string.concat
Exemple :
string messageErr = " Type : " + eventType.ToString() + " - message : "+ message + "\r\n";
devient
string messageErr = string.Concat(" Type : {0} - message : {1}\r\n",eventType.ToString(),message).

C'est plus propre et plus lisible ;)
Messages postés
2
Date d'inscription
lundi 9 mars 2009
Statut
Membre
Dernière intervention
11 mars 2009

Je débute cela m'aide énormément, merci pour ton travail
Afficher les 11 commentaires