He leído en varias fuentes, incluido el blog 'Ploeh' de Mark Seemann, acerca de cómo la ubicación adecuada de la raíz de composición de un contenedor de IoC está lo más cerca posible del punto de entrada de una aplicación.
En el mundo .NET, estas aplicaciones parecen ser comúnmente consideradas como proyectos web, proyectos WPF, aplicaciones de consola, cosas con una interfaz de usuario típica (léase: no proyectos de biblioteca).
¿Va realmente en contra de este sabio consejo colocar la raíz de composición en el punto de entrada de un proyecto de biblioteca, cuando representa el punto de entrada lógico de un grupo de proyectos de biblioteca, y el cliente de un grupo de proyecto como este es el trabajo de otra persona? , cuyo autor no puede o no agregará la raíz de la composición a su proyecto (un proyecto de IU u otro proyecto de biblioteca, incluso)?
Estoy familiarizado con Ninject como una implementación de contenedor IoC, pero imagino que muchos otros funcionan de la misma manera, ya que pueden escanear en busca de un módulo que contenga todas las configuraciones de enlace necesarias. Esto significa que podría poner un módulo de enlace en su propio proyecto de biblioteca para compilarlo con la salida de mi proyecto de biblioteca principal, y si el cliente quisiera cambiar la configuración (un escenario poco probable en mi caso), podrían colocar un dll de reemplazo para reemplazar el biblioteca con el módulo de enlace.
Esto parece evitar que los clientes más comunes tengan que lidiar con la inyección de dependencia y las raíces de composición, y sería la API más limpia para el grupo de proyectos de la biblioteca.
Sin embargo, esto parece ir en contra de la sabiduría convencional sobre el tema. ¿Es solo que la mayoría de los consejos por ahí suponen que el desarrollador también tiene cierta coordinación con el desarrollo de los proyectos de IU, en lugar de mi caso, en el que solo estoy desarrollando bibliotecas para que otros los usen?
La belleza de las bibliotecas externas es que deberían hacer lo que sea que digan que harían, al tiempo que exponen una interfaz simple y directa. Lo complejo que sea realmente hacerlo, no debería ser asunto del desarrollador que lo implementa. Si DI realmente hace que el trabajo del desarrollador de API sea menos complejo, entonces tiene 100% de sentido usarlo, siempre que se use correctamente y su módulo se declare en el punto de entrada de la API. Al desarrollar una aplicación MVC recientemente, abstraje la capa de datos utilizando un patrón de repositorio y aún más abstrayendo colocando una capa de servicio entre la aplicación MVC y la capa de repositorio, ambos proyectos de Class Library. Tenía una interfaz ICache asignada a una clase de caché para mi contexto de servicio. Inicialmente lo implementé usando MVC.Web.Cache, pero en una iteración posterior lo cambié por System.runtime. caché y solo puedes imaginar cuán grande habría sido la escala de ese Refactor sin mi DI de uso. Entonces mi consejo; "Ve a por ello".
fuente