inversion of control - injection - ¿Patrón abstracto de fábrica encima de IoC?
dependency injection controller c# (2)
Bueno, en la parte superior de la aplicación, necesitará una clase Bootstrap que cargue el contexto IOC. Este contexto proporcionará los objetos realmente instanciados y, por lo tanto, actuará como una fábrica.
Pero esto solo debería ocurrir con muy pocos objetos y el usuario de su clase Bootstrap / Factory debería saber lo menos posible sobre la arquitectura subyacente. Por ejemplo, si configuró un objeto de servidor HTTP completamente a través de IOC y desea iniciarlo, su clase Bootstrap solo necesita proporcionar un método getHttpServer (). Entonces, el método principal de su programa solo necesita llamar a Bootstrap.getHttpServer (). Start () para que se ejecute.
El contexto de la aplicación ya ha realizado el cableado de sus otros objetos. Por ejemplo, configura el Objeto A a través de IOC, que forma parte del Objeto B, de modo que configura el Objeto B con la referencia al Objeto A. Ninguno de ellos generalmente no necesita conocer el contenedor. ni la fabrica.
He decidido utilizar los principios de la IoC en un proyecto más grande. Sin embargo, me gustaría aclarar algo que me ha estado molestando durante mucho tiempo. La conclusión a la que he llegado es que un contenedor IoC es un patrón arquitectónico, no un patrón de diseño. En otras palabras, ninguna clase debe ser consciente de su presencia y el contenedor en sí debe usarse en la capa de aplicación para coser todos los componentes. Esencialmente, se convierte en una opción, además de un modelo bien diseñado orientado a objetos. Dicho esto, ¿cómo es posible acceder a los tipos resueltos sin tener que rociar contenedores IoC por todo el lugar (independientemente de si están resumidos o no)? La única opción que veo aquí es utilizar fábricas abstractas que utilizan un contenedor IoC para resolver tipos concretos. Esto debería ser lo suficientemente fácil de cambiar por un conjunto de fábricas estándar. ¿Es este un buen enfoque? ¿Alguien de aquí lo ha usado y qué tan bien funcionó para usted? ¿Hay algo más disponible?
¡Gracias!
Como ya ha descubierto, la inyección de dependencia (DI) en sí misma es solo una colección de patrones y técnicas.
En la raíz de la aplicación, conectamos todos los gráficos de objetos necesarios. Este lugar se llama la raíz de composición , y podemos usar un contenedor DI para hacer este cableado por nosotros, o podemos hacerlo manualmente ( Pure DI ).
El punto es que solo hay un lugar en su aplicación donde hay una fuerte referencia a una pieza particular de tecnología (su contenedor DI). El resto de la aplicación no tiene ni idea de cómo se conectó el gráfico del objeto. Lo único que importa es que todas las dependencias requeridas se inyectaron correctamente (y puede usar la Inyección de constructor con protectores nulos para garantizar que esto sea así).
El patrón Abstract Factory es un patrón muy útil cuando se trata de DI. En esencia, use Abstract Factory cuando:
- Debe proporcionar uno o más parámetros que solo se conocen en tiempo de ejecución antes de poder resolver una dependencia.
- La vida útil de la dependencia es conceptualmente más corta que la vida útil del consumidor.
Los ejemplos y más información están disponibles aquí: