Inversión de Control:

En inglés, conocido como Inversion of Control (IoC), es un estilo de programación en el cual

un framework o librería controla el flujo de un programa. Esto es un cambio con respecto a
paradigmas tradicionales donde el programador especifica todo el flujo del programa. Sin
conocerlo, estamos usando IoC indirectamente al desarrollar aplicaciones con el framework
.NET de Microsoft, por ejemplo: cuando creamos una aplicación ASP.NET nosotros
conocemos cuál es el ciclo de vida de una página, pero no lo controlamos ya que es
ASP.NET el que lo hace, o cuando creamos aplicaciones de escritorio o móviles, los
formularios también tienen su ciclo de vida que controla el framework.

https://hernandgr.wordpress.com/2014/08/13/que-es-la-inversion-de-control-y-la-
inyeccion-de-dependencias/

Seguramente muchos de nosotros ya hemos escuchado el término Inversion of control

(Inversión de control) más de una vez, incluso otros, ya los están utilizando sin saberlo. Lo
cierto es que cada vez es más común escuchar este término y es que ha revolucionado por
completo la forma trabar con los Frame Works.
Inversion of control (IoC) es una forma de trabajar que rompe con el formato tradicional, en
donde el programar es el encargado de definir la secuencia de operaciones que se deben
de realizar para llegar a un resultado. En este sentido el programador debe conocer todos
los detalles del framework y las operaciones a realizar en él, por otra parte, el Framework
no conoce absolutamente nada de nuestro programa. Es decir, solo expone operaciones
para ser ejecutada. La siguiente imagen muestra la forma de trabajo normal.

Veamos que nuestra aplicación es la que llama en todo momento al Framework y este hace
lo que la App le solicita. Por otra parte, al Framework no le interesa en absoluto la App.
Pero qué pasaría si invirtiéramos la forma de trabajo, y que en lugar de que la App llame
funciones del Framework, sea el Framework el que ejecute operaciones sobre la App,
¿suena extraño no? Pues en realidad a esta técnica es a la que se le conoce como Inversion
of Control. Veamos en la siguiente imagen como es que funciona IoC:
Esta última imagen se ve bastante parecida a la anterior, sin embargo, tiene una gran
diferencia, y es que las llamadas se invirtieron, ahora es el Framework es el realiza
operaciones sobre nuestra App.
Seguramente a estas alturas te pregunta cómo es que un Framework que no conoce tu App
y que incluso se compilo desde mucho antes puede realizar operaciones sobre nuestra App.
La respuesta es simple pero complicada, y es que utilizar este IoC es mucho más simple
de lo que parecería, pero implementar un Framework de este tipo tiene un grado alto de
complejidad, dicho de otra manera, si tú eres la App puedes implementar muy fácilmente al
Framework, pero si tu estas desarrollando el Framework puede ser un verdadero dolor de
cabeza.
Pues bien, IoC se basa en la introspección (en Java llamado Reflection) el cual es un
procedimiento por el cual leemos metadatos de la App que nos permita entender cómo
funciona, los metadatos pueden estar expresados principalmente de dos formas, la primera
es mediante archivos de configuración como XML o con metadados directamente definidos
sobre las clases de nuestro programa, en Java estos metadatos son las @Annotations o
anotaciones y es por medio de estos metadatos y con técnicas de introspección que es
posible entender el funcionamiento de la App.
NOTA: La introspección son técnicas para analizar clases en tiempo de ejecución, mediante
esta es posible saber las propiedades, métodos, clases que extiende e implementa, ejecutar
operaciones, settear u obtener valores, etc. y todo esto sin saber absolutamente nada de la
clase.
Otra de los problemas que intenta solucionar IoC es la de evitar utilizar el operador new
para crear clases clave o que son gestionadas por el Framework. En su lugar el Framework
creará estos objetos por nosotros y nos podrá a disposición por medio de inyección de
dependencias.
Pero analicemos un ejemplo concreto. Imaginemos que crearemos un Framework para
gestionar la capa de servicios y la persistencia. Veamos la siguiente clase:

package com.oscarblancarte.ioc;
import javax.annotation.Resource;

/**
* @author Oscar Blancarte
*/
@Service
public class EmployeeService {

private TransactionManager tran;

public EmployeeService(){}

@Resource
public void setTransactionManager(TransactionManager tran){
this.tran = tran;
}

@Transaction
public void saveEmployee(Employee emp){
tran.persist(emp);
}
}

Primero que nada, es importante resaltar que el siguiente ejemplo ilustrativo por lo que no
tiene porque no te funcionara si lo tratas de compilar. Ya con esa aclaración, analicemos el
ejemplo. Lo primero que vemos es una clase anotada con @Service, esto le indicara a
nuestro Framework que es una clase se servicios y que debe de ser gestionada por él, la
segundo que vemos es el método setTransactionManager el cual recibe un objeto de tipo
TransactionManager, el método esta anotado con @Resource, lo que le indita al Framework
que ese método debe de ser utilizado para inyectar un TransactionManager. Finalmente
vemos el método saveEmployee, el cual esta anotado con @Transaction lo que le indicara
al Framework que todo lo que se realice en ese método debe de ser trabajado bajo una
transacción, el método recibe el empleado a guardar.
Ya con la explicación de la clase vemos a entrar en algunos detalles importantes. Primero
que nada, esta clase deberá ser instanciada únicamente por Framework, ya que este al
crear la instancia ejecutará el método setTransactionManager para establecer un valor a la
variable tran. Seguido cuando el método saveEmployee sea ejecutado será el Framework
quien abra la transacción por nosotros y la cerrar cuando la ejecución del este termine.
Finalmente, cuando el servicio ya no sea requerido será destruido de forma automática y
los recursos como Conexiones a base de datos serán liberadas. Veamos la siguiente
imagen para entender que está pasando:

Analicemos la imagen, primero el Framework analizará al App mediante los metadatos, este
encontrará la clase EmployeeService que esta anotada con @Service, seguido le inyectará
una instancia del TrasnactionManager mediante el método setTransactionManager que
esta anotado con @Resource, finalmente el servicio será retornado a la App para ser
utilizado.
Cabe mencionar que los proxys son clave para controlar como la forma en que el usuario
utiliza las operaciones. Puedes encontrar mucho más de este patrón en mi libro.
¿Pero qué pasaría si nos brincamos el Framework y creamos manualmente la clase? Bueno
la respuesta es clara, la variable tran no será inyectada y valdrá null, seguido la
transaccionalidad del método saveEmployee no servirá de nada, pues solo tendrá un
metadato que nadie utiliza.
Bueno, eso ha sido una pequeña introducción al concepto de Inversion of Control, espero
que sea lo suficiente mente claro, pues el concepto y sobre todo la implementación pueden
llegar a ser complejas.
https://www.oscarblancarteblog.com/2016/12/01/concepto-inversion-of-control/

La inversión del control es un fenómeno común con el que se encuentra al extender los
marcos. De hecho, a menudo se ve como una característica definitoria de un marco.
Consideremos un ejemplo simple. Imagine que estoy escribiendo un programa para obtener
información de un usuario y estoy usando una consulta de línea de comando. Podría
hacerlo algo como esto
#rubí
pone '¿Cuál es tu nombre?'
 nombre = obtiene
nombre_proceso (nombre)
pone '¿Cuál es tu búsqueda?'
búsqueda = obtiene
process_quest (búsqueda)
En esta interacción, mi código está en control: decide cuándo hacer preguntas, cuándo leer
las respuestas y cuándo procesar esos resultados.
Sin embargo, si tuviera que usar un sistema de ventanas para hacer algo como esto, lo
haría configurando una ventana.
requiere 'tk'
root = TkRoot.new ()
name_label = TkLabel.new () {text "¿Cuál es tu nombre?"}
name_label.pack
nombre = TkEntry.new (root) .pack
name.bind ("FocusOut") {nombre_proceso (nombre)}
quest_label = TkLabel.new () {text "¿Cuál es tu búsqueda?"}
quest_label.pack
quest = TkEntry.new (root) .pack
quest.bind ("FocusOut") {process_quest (quest)}
Tk.mainloop ()
Hay una gran diferencia ahora en el flujo de control entre estos programas, en particular el
control de cuándo se llaman los métodos process_namey process_quest. En el formulario
de línea de comando, controlo cuándo se llaman estos métodos, pero en el ejemplo de la
ventana no. En cambio, entrego el control al sistema de ventanas (con
el Tk.mainloopcomando). Luego decide cuándo llamar a mis métodos, en función de los
enlaces que hice al crear el formulario. El control está invertido: me llama más bien a mí,
llamando al marco. Este fenómeno es la Inversión de control (también conocido como el
Principio de Hollywood: "No nos llame, lo llamaremos").
Una característica importante de un marco es que los métodos definidos por el usuario para
adaptar el marco a menudo se invocarán desde el marco mismo, en lugar del código de
aplicación del usuario. El marco a menudo desempeña el papel del programa principal en
la coordinación y secuencia de la actividad de la aplicación. Esta inversión de control da a
los marcos el poder de servir como esqueletos extensibles. Los métodos proporcionados
por el usuario adaptan los algoritmos genéricos definidos en el marco para una aplicación
particular.
- Ralph Johnson y Brian Foote
La inversión del control es una parte clave de lo que hace que un marco sea diferente a una
biblioteca. Una biblioteca es esencialmente un conjunto de funciones a las que puede
llamar, en estos días generalmente organizadas en clases. Cada llamada hace algo de
trabajo y devuelve el control al cliente.
Un marco incorpora un diseño abstracto, con más comportamiento incorporado. Para
usarlo, debe insertar su comportamiento en varios lugares del marco, ya sea
subclasificando o conectando sus propias clases. El código del marco luego llama a su
código en estos puntos.
Hay varias formas de conectar su código para que lo llamen. En el ejemplo anterior de ruby,
invocamos un método de enlace en el campo de entrada de texto que pasa un nombre de
evento y una Lambda como argumento. Cada vez que el cuadro de entrada de texto detecta
el evento, llama al código en el cierre. Usar cierres como este es muy conveniente, pero
muchos idiomas no los admiten.
Otra forma de hacerlo es hacer que el marco defina eventos y que el código del cliente se
suscriba a estos eventos. .NET es un buen ejemplo de una plataforma que tiene
características de lenguaje para permitir a las personas declarar eventos en widgets. Luego
puede vincular un método al evento utilizando un delegado.
Los enfoques anteriores (son realmente los mismos) funcionan bien para casos
individuales, pero a veces desea combinar varias llamadas a métodos requeridos en una
sola unidad de extensión. En este caso, el marco puede definir una interfaz que un código
de cliente debe implementar para las llamadas relevantes.
Los EJB son un buen ejemplo de este estilo de inversión de control. Cuando desarrolle un
bean de sesión, puede implementar varios métodos que son llamados por el contenedor
EJB en varios puntos de ciclo de vida. Por ejemplo las define la interfaz Bean de
sesión ejbRemove, ejbPassivate(almacenada en el almacenamiento secundario),
y ejbActivate(restaurada de un estado pasivo). No puedes controlar cuándo se llaman estos
métodos, solo lo que hacen. El contenedor nos llama, nosotros no lo llamamos.
Estos son casos complicados de inversión de control, pero se encuentra con este efecto en
situaciones mucho más simples. Un método de plantilla es un buen ejemplo: la superclase
define el flujo de control, las subclases extienden estos métodos de anulación o
implementan métodos abstractos para hacer la extensión. Entonces, en JUnit, el código
marco llama setUpy los tearDownmétodos para que pueda crear y limpiar su dispositivo de
texto. Hace la llamada, su código reacciona, por lo que nuevamente se invierte el control.
Hay cierta confusión en estos días sobre el significado de la inversión de control debido al
aumento de los contenedores de IoC; Algunas personas confunden el principio general aquí
con los estilos específicos de inversión de control (como la inyección de dependencia ) que
utilizan estos contenedores. El nombre es algo confuso (e irónico) ya que los contenedores
de IoC generalmente se consideran como un competidor de EJB, sin embargo, EJB usa la
inversión de control tanto (si no más).
Etimología: Por lo que puedo decir, el término Inversión de control salió a la luz por primera
vez en el artículo de Johnson and Foote Designing Reusable Classes , publicado por el
Journal of Object-Oriented Programming en 1988. El artículo es uno de los que ha
envejecido bien: es Vale la pena leerlo ahora más de quince años después. Piensan que
obtuvieron el término de otro lugar, pero no pueden recordar qué. El término luego se
insinuó en la comunidad orientada a objetos y aparece en el libro Gang of Four . El
sinónimo más colorido 'Principio de Hollywood' parece originarse en un artículo de Richard
Sweet sobre Mesa en 1983. En una lista de objetivos de diseño, escribe: "No nos llame, lo
llamaremos (Ley de Hollywood): una herramienta debe hacer los arreglos para que Tajo lo
notifique cuando el usuario desee comunicar algún evento a la herramienta, en lugar de
adoptar y pedirle al usuario un comando y ejecutarlo "modelo". John Vlissides escribió
una columna para el informe de C ++ que proporciona una buena explicación del concepto
bajo el apodo de "Principio de Hollywood". (Gracias a Brian Foote y Ralph Johnson por
ayudarme con la Etimología).

https://martinfowler.com/bliki/InversionOfControl.html

Inversión de control (Inversion of Control en inglés, IoC) es un principio de diseño de

software en el que el flujo de ejecución de un programa se invierte respecto a los métodos
de programación tradicionales. En los métodos de programación tradicionales la interacción
se expresa de forma imperativa haciendo llamadas a procedimientos o funciones.
Tradicionalmente el programador especifica la secuencia de decisiones y procedimientos
que pueden darse durante el ciclo de vida de un programa mediante llamadas a funciones.
En su lugar, en la inversión de control se especifican respuestas deseadas a sucesos o
solicitudes de datos concretas, dejando que algún tipo de entidad o arquitectura externa
lleve a cabo las acciones de control que se requieran en el orden necesario y para el
conjunto de sucesos que tengan que ocurrir.
Esta nueva filosofía es muy útil cuando se usan frameworks de desarrollo. Es el framework
el que toma el control, el que define el flujo de actuación o el ciclo de vida de una petición.
Es decir, es el framework quien ejecuta el código de usuario.1
La inversión de control es un término genérico que puede implementarse de diferentes
maneras. Por ejemplo se puede implementar mediante eventos o mediante Inyección de
Dependencias.2

https://es.wikipedia.org/wiki/Inversi%C3%B3n_de_control

Inversión de control en C #
En este artículo, voy a discutir la Inversión de Control en C #. Lea nuestro artículo anterior,
donde discutimos elPatrón de diseño abstracto de fábrica en C # con ejemplos. Como
desarrollador, puede estar familiarizado con los términos IoC (Inversion of Control), DIP
(Dependency Inversion Principle), DI (Dependency Injection) Design pattern y IoC
container. ¿Pero está seguro de lo que significa cada término con algunos ejemplos en
tiempo real? Si no está seguro acerca de cada uno de estos términos, entonces está en el
lugar correcto. Aquí discutiremos cada uno de estos términos. Como parte de este artículo,
vamos a discutir los siguientes consejos.
1. Diferencia entre Principio de diseño y Patrón de diseño
2. Inversión de control (IoC)
3. Comprensión del principio de inversión de dependencia.
4. Comprender el patrón de diseño de inyección de dependencia
5. Contenedor de IoC
Diferencia entre Principio de diseño y Patrón de diseño
En el mundo de la programación, tanto los principios de diseño como los patrones de diseño
no son lo mismo.Discutamos las diferencias entre ellos.
Principio de diseño:
Los principios de diseño se proporcionan con algunas pautas de alto nivel o puede decirse
un mecanismo para hacer que los diseños de software sean más comprensibles, flexibles
y fáciles de mantener. Ellos (es decir, los Principios de diseño) no proporcionan ninguna
implementación y tampoco están vinculados a ningún lenguaje de programación. Por lo
tanto, puede utilizar los principios de diseño independientemente de los lenguajes de
programación.
Por ejemplo, principios de diseño SOLID (SRP, OCP, LSP, ISP, DIP).
Por ejemplo, el Principio de Responsabilidad Única (SRP) establece que una clase debe
tener solo una razón para cambiar. Esta es la declaración de alto nivel que debemos tener
en cuenta al diseñar las clases para nuestra aplicación. El SRP no proporciona ningún paso
de implementación específico, pero depende de nosotros cómo implementamos el Principio
de responsabilidad única en nuestra aplicación.
Patrón de diseño:
Los patrones de diseño son soluciones reutilizables a los problemas que encontramos en
nuestra programación diaria. Básicamente se utilizan para resolver los problemas de
generación e integración de objetos. Por ejemplo, si desea crear una clase que pueda tener
solo una instancia para toda la aplicación, entonces puede usar el patrón de diseño
Singleton que garantiza que una clase tenga solo una instancia para toda la aplicación y
proporcione un punto de acceso global.
Hay tantos patrones de diseño que otros prueban y que es seguro seguir. Por
ejemplo. Banda de cuatro patrones: Fábrica abstracta, Fábrica, Singleton, etc.
Una vez que comprenda la diferencia entre los Patrones de diseño y los Principios de
diseño , comprendamos los términos IoC (Inversión de control), DIP (Principio de inversión
de dependencia), Patrón de diseño DI (Inyección de dependencia) y Contenedores de IoC .
El siguiente diagrama le da una idea clara de si son principios, patrones o marcos.

Como principios, solo proporcionan algunas pautas o mecanismos de alto nivel para
desarrollar aplicaciones de software, pero no proporcionan detalles de implementación
específicos. La inyección de dependencia es un patrón de diseño, mientras que el
contenedor IoC es un marco.
Echemos un vistazo a cada término antes de entrar en detalles.
Inversión de control (IoC):
El objetivo principal de la Inversión de control (IoC) es eliminar las dependencias entre los
objetos de una aplicación, lo que hace que la aplicación esté más desacoplada y sea más
fácil de mantener.
El principio de diseño de IoC sugiere la inversión de varios tipos de controles en el diseño
orientado a objetos para lograr un acoplamiento flexible entre las clases de aplicación. Aquí,
el control significa cualquier responsabilidad adicional que una clase tenga además de su
responsabilidad principal o fundamental. Por ejemplo, control sobre el flujo de una
aplicación, control sobre la creación de objetos dependientes, etc.
Supongamos que tiene una clase de " repositorio " y que la clase de repositorio es
responsable de proporcionarle datos de una fuente de datos.
La clase de repositorio podría establecer una conexión con la fuente de datos por sí misma
sin la entrada de nadie más. Pero, considere la situación, ¿qué pasa si se le permite pasar
los detalles de conexión sobre la fuente de datos a través del constructor de la clase de
repositorio?
Al permitir que la persona que llama proporcione los detalles de la conexión a través de un
constructor de clase, en realidad hemos desacoplado la dependencia de conexión de la
fuente de datos de la clase de repositorio, permitiendo que cualquier fuente de datos trabaje
con el repositorio, no la que especifica el repositorio.
Aquí, hemos invertido el control al transferir la responsabilidad de crear los detalles de
conexión sobre la fuente de datos desde la clase de repositorio a la clase de llamante.
Martin Fowler recomienda usar el término "Inyección de dependencia" para describir este
tipo de Inversión de control, ya que la Inversión de control es un principio, puede utilizarse
de manera más integral que simplemente inyectar dependencias en un método de
construcción.
Discutiré IoC en detalle en el próximo artículo.
Comprensión del principio de inversión de dependencia:
El principio de inversión de dependencia también nos ayuda a lograr un acoplamiento
flexible entre las clases.Se recomienda encarecidamente utilizar DIP e IoC juntos para
lograr un acoplamiento flexible entre las clases.
El DIP (DIP) establece que los módulos / clases de alto nivel no deberían depender de
módulos / clases de bajo nivel. Ambos deberían depender de abstracciones. En segundo
lugar, las abstracciones no deberían depender de los detalles. Los detalles deben depender
de las abstracciones.
Necesitamos mantener el módulo de alto nivel y el módulo de bajo nivel lo más acoplados
posible.
Cuando una clase sabe sobre el diseño y la implementación de otra clase, aumenta el riesgo
de que si hacemos algún cambio en una clase se rompa la otra clase. Por lo tanto, debemos
mantener estos módulos / clases de alto y bajo nivel acoplados lo más libremente
posible. Para hacer eso, debemos hacer que ambos dependan de abstracciones en lugar
de conocerse.
El principio DIP es inventado por Robert Martin (también conocido como tío Bob). Es
fundador de los principios SOLID. Discutiremos DIP en detalle en nuestros próximos
artículos.
Comprensión del patrón de diseño de inyección de dependencia:
El patrón de diseño de Inyección de dependencias (DI) es un patrón de diseño de software
que nos permite desarrollar código débilmente acoplado al invertir la creación de objetos
dependientes.
La inyección de dependencia es una excelente manera de reducir el acoplamiento estrecho
entre los componentes del software. DI también nos permite gestionar mejor los cambios
futuros y otra complejidad en nuestro software.
Contenedor IoC:
IoC Container es un excelente marco para crear dependencias e inyectarlas
automáticamente cuando sea necesario en toda la aplicación, de modo que nosotros, como
programadores de software, no tengamos que dedicarle más tiempo y esfuerzo. Crea
automáticamente los objetos necesarios en función de la solicitud y también los inyecta
automáticamente cuando sea necesario. DI Container nos ayuda a administrar las
dependencias dentro de la aplicación de una manera simple y directa.
Hay diferentes IoC Containers disponibles para .NET, como Unity, Ninject, StructureMap,
Autofac, etc. Discutiré más sobre el capítulo IoC Container en nuestros próximos artículos.
No podemos lograr clases poco acopladas simplemente utilizando IoC. Junto con IoC,
también necesitamos utilizar contenedores DIP, DI e IoC para lograr un acoplamiento
flexible.
El siguiente diagrama ilustra cómo vamos a lograr un diseño débilmente acoplado paso a
paso en los próximos artículos próximos.
En el siguiente artículo, voy a discutir la Inversión de Control usando el Patrón de Fábrica
en C # con ejemplos. Aquí, en este artículo, trato de explicar el que nVersión de control en
C # . Espero que este artículo te ayude con tus necesidades. Me gustaría recibir sus
comentarios. Publique sus comentarios, preguntas o comentarios sobre este artículo.

https://dotnettutorials.net/lesson/introduction-to-inversion-of-control/