Quel est l'intérêt d'une façade d'exploitation forestière ?

Question

Il existe un grand nombre de bibliothèques de journalisation différentes, chacune ayant ses propres particularités et avantages. ( Exemples .NET : log4net, System.Diagnostics.TraceSource, NLog, etc.)

La tendance naturelle est de faire abstraction de ces particularités et d'utiliser une façade d'enregistrement. (exemples : Castle.Services.Logging , Logging.commun , Facade de journalisation simple ) De cette façon, si le cadre de journalisation que vous utilisez devient obsolète ou si un autre cadre est en vogue, vous pouvez simplement changer l'implémentation et laisser le code intact.

Mais il existe de multiples façades d'exploitation forestière parmi lesquelles choisir. Étant donné que la réponse aux nombreuses implémentations disparates de journalisation était l'abstraction, pourquoi ne pas utiliser une façade de journalisation ? Si cela semble ridicule, qu'est-ce qui le rend plus ridicule que la façade de journalisation originale ? Qu'est-ce qui fait qu'une couche supplémentaire d'abstraction au-dessus de la structure de journalisation est le nombre magique ?

Answer 1

Ce n'est pas le nombre magique, cela dépend de la flexibilité que vous voulez avoir. Si vous pensez changer la façade du journal un jour, vous devriez écrire une façade de façade. Si vous pensez changer seulement le rondin vous avez besoin d'une façade. Si vous ne pensez à rien, n'utilisez pas de façade.

L'inconvénient, comme vous l'avez dit, ce sont les capacités spéciales. Si vous les utilisez, n'écrivez que votre propre façade.

Answer 2

Dans cet exemple, vous n'avez besoin que d'un seul niveau d'abstraction pour pouvoir échanger votre logger.

Quel avantage supplémentaire vous apporterait le fait de pouvoir échanger votre façade d'exploitation forestière ?

Answer 3

Il est utilisable dans le protocole pour le système de plugin. Au lieu de dire use Some3rdParty.dll and MyPlugingApi.dll Je ne documenterais que MyPlugingApi.dll . L'interface de la façade de journalisation suggérera et documentera certaines utilisations qui conduiront probablement à des journaux lisibles et à des performances de journalisation suffisantes. Et bien sûr, ces changements n'entraîneront pas de modifications de l'API du plugin.

Pourquoi faut-il changer la mise en œuvre ? Cela peut se produire si l'implémentation actuelle semble lente à démarrer à partir de la configuration ou lente à écrire des entrées, si l'on souhaite étendre l'implémentation à une version réduite de .NET qui ne dispose pas de la tierce partie nécessaire, si l'on souhaite intégrer une autre base de code qui utilise d'autres enregistreurs de journaux.

J'ai aussi écrit un autre façade qui est l'enfant des pensées dans cette réponse.

Answer 4

Je ne suis en aucun cas un expert, mais dans notre groupe, la valeur de la façade n'est pas de nous donner la possibilité de changer le cadre de journalisation. Il est vrai que c'est quelque chose que nous obtenons, mais nous sommes dans la catégorie de ceux qui sont très peu susceptibles de changer leur cadre.

Dans notre cas, nous utilisons une façade pour personnaliser l'enregistrement. interface aux besoins de notre application. Nous avons constaté que tous les cadres sémantiques que nous avons examinés étaient encore trop axés sur ce que nous appelons le modèle "médico-légal" de la journalisation - quelqu'un qui fouille dans les journaux à la recherche d'une ligne de sortie dans le but d'analyser un événement.

Bien que ce soit un cas d'utilisation pour nous aussi, ce n'est pas notre cas d'utilisation principal. Nous voulons plutôt un instrumentation qui nous permettra de signaler les éléments intéressants, même ceux auxquels nous n'avons pas pensé au moment de la mise en œuvre.

Par exemple, notre application n'a pas besoin d'un "message" pour accompagner un événement ; au lieu de cela, notre "logger" acceptera des enums définissant le type d'événement et des objets d'état représentant des spécificités (par exemple, des horodatages ou d'autres valeurs) et les sérialisera pour faciliter la production de rapports, l'analyse de perforation, les mesures de la valeur commerciale, etc. (Nous reconnaissons que nous rendons, en fait, l'analyse traditionnelle un peu plus difficile au profit d'une interface de journalisation simple à utiliser et à comprendre qui augmente la probabilité que nous l'utilisions réellement et plus souvent).

Donc, pour vous donner une réponse succincte, voici un ordre approximatif des avantages que nous pensons tirer de l'utilisation d'une façade de journalisation.

1. Une interface cohérente et adaptée faciliter l'instrumentation (par opposition à la simple consignation traditionnelle, comme indiqué plus haut)
2. Points de test simulables
3. Implémentations d'enregistreurs injectables convient pour tout, du développement local aux connexions AWS S3 ou DB, en fonction du déploiement (notre application utilise Autofac avec injection de dépendance de constructeur)
4. Cadres de logger substituables ce qui nous permettra de passer à un autre cadre de journalisation à l'avenir si nous le souhaitons. (Incidemment, nous ne prévoyons pas que cela se produise, donc, en soi, cela ne nous aurait pas convaincus d'utiliser une façade).

Et enfin, 0 façade perdrait ces avantages, et 2 façades n'ajouteraient à aucun de ces avantages, c'est pourquoi 1 façade est le bon chiffre pour nous.

Excellente question, @brian ! :)