¿Vale la pena envolver un marco de registro en una capa adicional?

Question

Actualmente estoy buscando la actualización del mecanismo de registro en una base de código Java de tamaño mediano a grande. Los mensajes se registran actualmente usando métodos estáticos en una clase Debug, y he recomendado cambiar de esto a algo así como SLF4J o registro de uso común.

El arquitecto de la aplicación prefiere que encapsule la dependencia en SLF4J (posiblemente envolviéndolo en la clase Debug antes mencionada). Esto hará que sea más fácil cambiar la implementación del registro en el futuro.

Esto me parece exagerado, ya que SLF4J ya está abstrayendo la implementación del registro concreto.

¿Vale la pena envolver una abstracción de registro de terceros como SLF4J en otra abstracción de cosecha propia?

Answer 1

Estoy completamente de acuerdo con usted: las envolturas de envoltorios de envoltorios están fuera de control. Sospecho que el arquitecto no se da cuenta de cómo SLF4J, en particular, puede ajustar fácilmente cualquier otro sistema de registro, por lo que "cambiar la implementación" es perfectamente factible sin otra capa de wrappage.

Answer 2

Si está pensando en cambiar marcos de registro en el futuro, puede valer la pena agregar una capa adicional a donde puede desconectar el registrador. De lo contrario, si proporcionan todo lo que posiblemente necesitará (usando su bola de cristal, por supuesto), entonces probablemente esté bien tener una dependencia dura de ese marco.

Si su configuración actual permite flexibilidad para cambiar, no necesita un contenedor.

Answer 3

Explique a su Architecture Astronaut que slf4j ya puede actuar como un contenedor para otras implementaciones de registro, como log4j. Entonces, si necesita usar algún otro registrador en el futuro y no hay un adaptador para slf4j, puede escribirlo cuando surja la necesidad, pero será el adaptador, en lugar de escribir un marco de trabajo de registro completo que simplemente envuelva a otros marco de registro y necesita diseñar su marco para eso y escribir su propio adaptador.

Answer 4

Preferiría envolverlo, pero no por el motivo indicado. Si la preocupación es la capacidad de cambiar para otro marco, use java.util.logging o SLF (java.util.logging no es tan fácil de usar como un contenedor, pero es bastante factible), y canjee. La razón para usar (otra) envoltura es codificar en código la forma apropiada de registro. En general, una aplicación desea un subconjunto, como por ejemplo, todos los errores del sistema vienen con una excepción, o tiene una guía específica sobre cuándo usar los niveles de registro estándar. Esas decisiones se pueden encapsular en unos pocos métodos para crear decisiones de registro más consistentes a lo largo de una gran base de código.

Si, sin embargo, la motivación es solo para posibilitar el cambio de implementaciones, no reinvente la rueda. SLF es perfecto para el trabajo, solo úsalo.

Hay una excepción a esto. Si su código está destinado a implementarse en muchos servidores de aplicaciones posibles sin problemas, debe asegurarse de que su opción de registro no entra en conflicto con las versiones más antiguas o nuevas de lo que sea que esté usando el marco.

Answer 5

El problema con cada envoltorio es la decisión de cómo va a envolver y de hecho, que la funcionalidad que va a proporcionar:

• commons.logging está proporcionando un conjunto mínimo de funcionalidad de registro, esconderse funcionalidad adicional que el marco subyacente podría proporcionar. No obtendrá funciones avanzadas como el registro parametrizado o el MDC.
• SLF4J funciona al revés. Maneja características avanzadas como el registro parametrizado al implementarlas sobre estructuras que no las están implementando de forma nativa. Esta es la mejor manera, en mi humilde opinión.

No conozco su clase actual de depuración, pero supongo que es bastante básica.

Es probable que no tienen características como

• la ubicación del registro de mensajes, es decir, el nombre del archivo de origen + número de línea
• diferentes niveles de registro
• la capacidad de fijar selectivamente el nivel de diferentes registradores, es decir, no tiene un registrador por clase, que tiene la capacidad de establecer ese registrador a un cierto nivel de interés, por ejemplo, INFO, WARN. Esto es bastante crucial.

Si la clase de depuración es bastante básico esto es realmente muy agradable para ti :)

Esto significa que lo más probable es capaz de cambiar a SLF4J mediante la realización de una búsqueda mundial dest &. .. err ... reemplazar.

hacer copias de seguridad, aunque ...;)

Ver también Should new projects use logback instead of log4j?, What’s Up with Logging in Java?, Which log4j facade to choose?, Find a way in the java logging frameworks scene. y Do you find java.util.logging sufficient?. (Spoiler: No debe usar java.util.logging, bonito por favor)

Answer 6

Supongo que la motivación detrás del deseo del arquitecto de envolver el envoltorio (es decir, SLF4J) es aislar su aplicación de SLF4J. Claramente, invocar la API SLF4J desde su aplicación crea una dependencia en SLF4J. Sin embargo, es igualmente legítimo querer aplicar el principio de aislamiento repetidamente como se explica a continuación. Me recuerda la pregunta de Richard Dawkins: si Dios creó el universo, ¿quién creó a Dios?

De hecho, también podría aplicar el principio de aislamiento en la envoltura que envuelve SLF4J. La causa del aislamiento estaría mal si el SLF4J-wrapper fuera de algún modo inferior al SLF4J. Aunque es posible, es bastante raro que una envoltura iguale o supere al original. SWT se puede citar como un contraejemplo digno de mención. Sin embargo, SWT es un proyecto considerable con un costo significativo. Más al punto, un SLF4J-wrapper por definición depende de SLF4J. Está obligado a tener la misma API general. Si en el futuro aparece una API de registro nueva y significativamente diferente, el código que usa el contenedor será igualmente difícil de migrar a la nueva API como código que usó SLF4J directamente. Por lo tanto, es probable que el envoltorio no proteja su código en el futuro, sino que lo haga más pesado agregando un indirecto adicional.

En resumen, incluso si no tenía nada mejor que hacer, no debe perder el tiempo envolviendo SLF4J porque el valor agregado de su envoltorio está garantizado que está cerca de cero.

El tema también se aborda en un SLF4J FAQ entry.