APIs de Logging para C#

El jueves veíamos que al traer Quartz con NuGet también traía una librería llamada Common.Logging, descubrimos después que sigue una estructura similar a la que trae su homónimo en Java, commons-logging.
Tal vez los que estuvieran viendo cosas en Java ahora, les suene slf4j que sería como una evolución de commons-logging.
¿Qué ventaja tienen? commons, slf4j, etc son APIs que nos permiten construir código abstrayéndonos de quién sea nuestro logger por detrás así no obligamos a quien corra nuestra aplicación (o framework) en usar alguno y no otro.
En la historia, commons recorría el class-loader de la VM buscando la “mejor opción”, cosa que después dio lugar a slf4j que usa otro método de “scan” más veloz y menos conflictivo con librerías externas.
Por lo pronto, en búsqueda de agilidad, poco me importó usar commons en C#, creí que sería como en Java que se daría cuenta cuál es el mejor logger. Después de alguans pruebas, me di cuenta que si no la configurábamos y le decíamos que estábamos usando log4net lo que terminaría pasando es que todos los logs que recibiera no los trataría, sencillamente porque no sabría cómo.
¿Cuál fue mi problema? Quartz loggeaba a través de commons y, como no estaba configurada no podía ver su logging. Sin duda que esto podría pasar con otros frameworks.
Nota: Esto no estaba pasando con nhibernate, que usa directamnete log4net.
En resumen, siempre que esté dentro de sus posibilidades, tiendan a usar una API de implementación de logging que nos dará un código más flexible y no complicaría (para nada) nuestra forma de codificar. Después de todo, los framework de logging están basados en log4net (o log4j) que es en lo que estamos acostumbrados.

Discussion Area - Leave a Comment