dependency-injection - latest - spring framework reference documentation
IoC, AOP y más (3)
¿Qué es un contenedor IoC?
¿Qué es un marco de IoC / DI?
¿Por qué necesitamos un marco para IoC / DI?
¿Hay alguna relación entre IoC / DI y AOP?
¿Qué es Spring.net/ninject con respecto a IoC y AOP?
JMSA,
James Kovacs escribió un fantástico artículo que cubre muchas de sus preguntas. Le recomendaría leerlo aquí.
Spring.Net, Ninject, Unity, Castle Windsor, Autofac son todos contenedores de COI configurables de diferentes maneras, muchos de ellos también admiten AOP.
Los marcos para IOC / DI son útiles porque proporcionan mecanismos estándar, por ejemplo, si está contratando un nuevo desarrollador, es mucho más fácil decirlo, usamos este marco y les pasamos los enlaces a los tutoriales / guía de ayuda. Al mismo tiempo, estos marcos son probados y probados por una gran comunidad / empresas.
Avíseme si alguna de sus preguntas permanece sin respuesta después de leer el artículo y las respuestas anteriores, y haré todo lo posible para brindarle más ayuda.
Martin Fowler tiene un buen artículo aquí sobre el significado de Inversion of Control y Dependency Injection.
El uso de Spring.NET AOP se describe en detalle aquí . Estoy más familiarizado con la versión de Spring basada en Java, por lo que no puedo decir con certeza que Spring.NET actualmente solo admita AOP basado en proxy.
Es decir, una clase a ser aconsejada debe implementar una interfaz. Spring creará un proxy dinámico que implementa esta interfaz y delega a la instancia de destino original.
Aunque dice:
En una versión futura, implementaremos los proxies utilizando la herencia, lo que le permitirá también proxyizar las clases sin interfaces y eliminará algunos de los problemas de referencia en bruto restantes que no se pueden resolver utilizando proxys basados en composición.
Desde un punto de vista semántico ...
La inyección de dependencias implica una dependencia , es decir, algo que se requiere para la construcción / uso (las "preocupaciones centrales" de la aplicación). Por ejemplo, un automóvil no es un automóvil sin motor.
Los aspectos se describen como transversales a las preocupaciones principales de la aplicación. Eso significa que es independiente y no crucial para las preocupaciones principales (se podría pensar que son "agradables para los que tienen"). Dado que la aplicación se puede ejecutar sin aspectos, ¿son realmente dependencias? Por ejemplo, un automóvil sigue siendo un automóvil incluso sin un inmovilizador.
(Por supuesto, esto es desde un punto de vista teórico. En el mundo real, cuestiones como la seguridad son a menudo tan cruciales para la existencia de un producto comercializable como el núcleo se ocupa de sí mismo).
Entonces, mientras que en la práctica DI se puede usar para implementar aspectos, no llamaría a ese proceso verdadero DI. Esto proviene de alguien que usa la inyección de constructor exclusivamente.