Registro, Programación Orientada a Aspectos e Inyección de Dependencia - Intentando darle sentido a todo

Question

Sé que el registro es un caso de uso principal para AOP. Además, los contenedores de registro también se ejemplifican como casos en los que se desea usar DI para que las clases no estén asociadas a una implementación de registro específica. Sin embargo, some consider logging wrappers an anti-pattern. Principalmente, tal visión se debe a que en la mayoría de los casos el contenedor tiende a ser simplista y elimina muchas de las características específicas del marco de trabajo de registro. Si implementa esas características específicas, ¿por qué no usar el marco directamente?

Soy consciente de la fachada Common.Logging que intenta abstraer una buena cantidad de las características de log4Net, EntLib, NLog para usted. Sin embargo, incluso aquí todavía tenemos una especie de dependencia en Common.Logging. No en una forma de prueba de código/unidad con respecto a las interfaces, pero si el proyecto fallece (ha pasado más de un año desde la última versión) o si desea cambiar a un registrador no compatible, eso puede causar problemas.

Dicho esto, si el registro se logra a través de AOP, ¿es necesario usar DI para la dependencia de registro (es decir, ¿por qué no solo hace referencia directa a decir NLog)? Sí, esa porción de código AOP estaría estrechamente acoplada, pero la lógica de las clases que uno quiere probar en una unidad carece de dependencias de registro (al menos antes de que ocurra el entrelazado). Es en este punto que estoy un poco perdido (todavía no he probado AOP). Después de tejer, ¿no habría usado DI para el código AOP causar problemas para probar la unidad del método bajo prueba? ¿O puede una unidad probar sin tejer el código AOP?

A menos que sea necesario que el usuario inicie sesión en el software, no estoy seguro de cuán útil es probar que el registro se haya producido con los simulacros. Creo que la lógica comercial del método bajo prueba es lo que más estaría interesado en probar. Por último, si uno quiere usar TDD/BDD, ¿no tendría que usar DI para las dependencias de registro en el código AOP? ¿O simplemente uno no test drive el lado AOP de las cosas?

Como puedes ver, estoy tratando de hacerte una idea de cuál es el enfoque más práctico para desarrollar una aplicación que usaría tanto AOP para preocupaciones transversales y DI para diseño/prueba. Como el AOP es relativamente nuevo, y el registro es el ejemplo más común, ¿cuál es el enfoque recomendado?

Answer 1

El registro no es un servicio, es un cross-cutting concern. Como tal, se implementa mejor con un Decorator. Sin embargo, agregar muchos decoradores solo para habilitar el registro de varios servicios diferentes suele violar DRY, en cuyo caso puede evolucionar aún más a esos decoradores en un solo interceptor.

Mientras que puede usar IL weaving para implementar AOP, una mejor opción es usar un DI Container que admita la intercepción dinámica, ya que es una solución mucho más ligera.

Esto le permite desacoplar completamente los servicios concretos del registro. En ese caso, entonces, diría que no hay razón para ajustar un marco de trabajo de registro en particular, porque si alguna vez quiere cambiar el marco de trabajo de registro, puede simplemente cambiar ese único Interceptor.

Here's an example que habla de decoradores e interceptores para la instrumentación (muy similar al registro).

Si desea obtener más información sobre AOP y DI, puede view online this talk I gave at GOTO Copenhagen 2010.