Usando IoC con objetos internos

Question

Actualmente estoy escribiendo un SDK de código abierto para un programa que uso y estoy usando un contenedor de IoC internamente (NInject) para conectar todas mis dependencias internas.

Tengo algunos objetos que están marcados como internos para no saturar la API pública, ya que solo se usan internamente y no deberían ser vistos por el usuario, como fábricas y otros objetos. El problema que tengo es que NInject no puede crear objetos internos, lo que significa que tengo que marcar todos mis objetos internos como públicos que saturan la API pública.

Mi pregunta es: ¿hay alguna forma de solucionar este problema o lo estoy haciendo todo mal?

PS. He pensado en usar el atributo InternalsVisiableTo, pero creo que es un poco oloroso.

Answer 1

Vista rápida de las otras respuestas: no parece que esté haciendo algo tan diferente que hay algo fundamentalmente incorrecto con Ninject que necesitaría modificarlo o reemplazarlo. En muchos casos, no puede '' ir directamente a [las] ??partes internas '' porque dependen de la inyección de dependencia no resuelta; de ahí el uso de Ninject en primer lugar. También parece que ya tiene un conjunto interno de interfaces, razón por la cual se planteó la pregunta.

Pensamientos: un problema con el uso de Ninject directamente en su SDK o biblioteca es que sus usuarios tendrán que usar Ninject en su código. Esto probablemente no sea un problema para usted porque es su elección de IoC, por lo que lo iba a usar de todos modos. ¿Qué pasa si quieren usar otro contenedor de IoC? Entonces, ahora efectivamente tienen dos esfuerzos de duplicación en ejecución. Peor aún, ¿qué pasa si quieren usar Ninject v2 y has usado v1.5? Eso realmente complica la situación.

Mejor caso: si puede refactorizar sus clases para que obtengan todo lo que necesitan a través de la Inyección de dependencias, entonces este es el más limpio porque el código de la biblioteca no necesita ninguno Contenedor de IoC. La aplicación puede conectar las dependencias y simplemente fluye. Sin embargo, esto no siempre es posible, ya que a veces las clases de la biblioteca necesitan crear instancias que tengan dependencias que no se puedan resolver mediante inyección.

Sugerencia: CommonServiceLocator (y el adaptador Ninject para ello) fueron diseñados específicamente para esta situación (bibliotecas con dependencias). Codifica contra CommonServiceLocator y luego la aplicación especifica qué DI / IoC respalda realmente la interfaz.

Es un poco molesto porque ahora tienes que tener Ninject y CommonServiceLocator en tu aplicación, pero CommonServiceLocator es bastante liviano. Su SDK / código de biblioteca solo usa CommonServiceLocator, que es bastante limpio.

Answer 2

Supongo que ni siquiera necesitas eso. IoC es para cosas públicas. Ir directamente a lo interno.

Pero, esa es solo mi intuición ...

Answer 3

Cree una API interna secundaria que sea diferente de la API externa. Es posible que deba hacer la división manualmente ...

Answer 4

Voy a votar por la solución InternalsVisibleTo. Totalmente no es un olor, de verdad. El objetivo del atributo es habilitar el tipo de comportamiento que desea, por lo que, en lugar de saltar a través de todo tipo de aros elaborados para que las cosas funcionen sin él, solo use la funcionalidad proporcionada por el marco para resolver este problema en particular.

También sugeriría, si desea ocultar al usuario su elección de contenedor, utilizando ILMerge para combinar los conjuntos Ninject con su conjunto SDK y aplicar el argumento / internalize para cambiar la visibilidad de los conjuntos Ninject interna, para que los espacios de nombres de Ninject no se filtren de su biblioteca (lo siento, no se pudo encontrar un enlace a los documentos de ILMerge en línea, pero hay un archivo de documentos en la descarga). También existe esta bonita publicación de blog sobre la integración de ILMerge en su proceso de compilación.

Answer 5

Puedes

• modificar Ninject
• elige un contenedor diferente