¿Qué es la inyección de dependencia en Spring?

La inyección de dependencia es un patrón de diseño central del marco Spring.

Primero comprendamos las cosas sin la inyección de dependencia.

Mire a continuación la implementación de un ExportService cuyo trabajo es exportar datos en formato pdf / csv.

La clase pública ExportServiceImpl implementa ExportService {

ExportDAO privado exportDao = nuevo ExportDAO ();

@Anular

exportación pública booleana (int exportFormat) {

return exportDao.exportData (exportFormat);

}

}

A primera vista, esta implementación se ve perfecta pero hay algunos problemas con esta implementación:

1) Cada ExportServiceImpl tiene su propia copia de ExportDAO, que es un objeto costoso ya que envuelve una conexión de base de datos. No tiene sentido crear instancias separadas de ExportDAO, si puede compartir una entre múltiples ExportService.

2) ExportServiceImpl está estrechamente relacionado con ExportDAO como su instancia creadora de ExportDAO usando el operador new (). Si cambia el constructor de ExportDAO, este código se romperá. Debido a este acoplamiento, es difícil reemplazar ExportDAO con una mejor implementación.

La Inyección de dependencias es un patrón de diseño en el que la dependencia del objeto (en este caso ExportDAO es una dependencia para el Objeto ExportServiceImpl) se inyecta mediante el marco en lugar de ser creado por el propio Objeto. La inyección de dependencia reduce el acoplamiento entre múltiples objetos, ya que el marco los inyecta dinámicamente. Una de las implementaciones de DI es la Inversión de control (IOC) en cuyo marco, como Spring, controla la dependencia del objeto. Existen principalmente dos tipos de inyección de dependencia: inyección de constructor e inyección de organismo .

En la Inyección del constructor, la dependencia del Objeto se inyecta usando el constructor, mientras que en la Inyección del instalador, la dependencia se proporciona mediante el método de establecimiento.

Ahora veremos cómo la inyección de dependencias resuelve todos los problemas anteriores que hemos enumerado con la implementación anterior de ExportService. Aquí hay una nueva implementación de ExportService con inyección de dependencia de setter.

La clase pública ExportServiceImpl implementa ExportService {

ExportDAO privado ExportDao;

public void setExportDaO (ExportDAO exportDao) {

this.exportDao = exportDao;

}

@Anular

exportación pública booleana (int exportFormat) {

return exportDao.exportData (exportFormat);

}

}

Obtuvimos las siguientes ventajas al usar DI.

1) Reducir el acoplamiento

Tanto la inyección de dependencia del constructor como la del setter reducen el acoplamiento. como en el ejemplo anterior, el acoplamiento entre ExportService y ExportDAO se reduce mediante el uso de la inyección de dependencia.

2) flexibilidad

Gracias a DI, puede reemplazar la implementación de no rendimiento por una mejor luego.

Si tiene una clase donde ha definido varias dependencias a clases externas. Veamos el siguiente ejemplo:

clase pública SimpleMovieLister {
// SimpleMovieLister depende de MovieFinder
MovieFinder privado MovieFinder;
// un constructor para que el contenedor Spring pueda ‘inyectar’ un MovieFinder
SimpleMovieLister público (MovieFinder movieFinder) {
this.movieFinder = movieFinder;
}
}

En el código anterior, SimpleMovieLister depende de la clase MovieFinder. Antes del concepto de inyección de dependencia (DI), uno tiene que crear la instancia de MovieFinder usando la palabra clave new () y usarla. Cada clase que tiene MovideFinder tiene que crear su propia instancia. De lo contrario, tienen que crear una clase de factor que cree una instancia para. Es una sobrecarga para administrar instancias en cada clase.

Solo piense si alguien más se encarga de crear y administrar las instancias por usted. Por lo tanto, todas las instancias de beans están centralizadas y solo solicitamos la inyección de esa instancia donde sea necesaria.

En el ejemplo anterior, la instancia de MovieFinder se inyectará utilizando el constructor. Estos se definen en las configuraciones XML.

Cuando creamos cualquier aplicación, hay muchas clases que dependen unas de otras para ejecutar alguna lógica de negocios. En ese caso, cualquier objeto que necesite otros objetos para hacer su trabajo, es responsable de obtener esas dependencias en sí (mediante el uso de una nueva palabra clave) de esa manera, esas clases están estrechamente unidas.

En caso de inyección de dependencia, los objetos no crearán sus dependencias ellos mismos, pero las dependencias se inyectarán en los objetos. La forma en que Spring ayuda con la inyección de dependencias es que puede definir sus beans en un archivo XML (también hay otras formas) y spring inicializará las clases y creará las asociaciones.

Lea más aquí: http://netjs.blogspot.com/2015/0

Cada aplicación Java tiene algunos objetos que trabajan juntos para presentar lo que el usuario final ve como una aplicación de trabajo. Al escribir una aplicación Java compleja, las clases de aplicación deben ser lo más independientes posible de otras clases Java para aumentar la posibilidad de reutilizar estas clases y probarlas independientemente de otras clases mientras se realizan pruebas unitarias. La inyección de dependencia (o en ocasiones llamada cableado) ayuda a pegar estas clases juntas y al mismo tiempo mantenerlas independientes.

DI existe en dos variantes principales y los siguientes dos subcapítulos cubrirán ambos con ejemplos:

Tipo de inyección de dependencia y descripción

1 inyección de dependencia basada en constructor

La DI basada en el constructor se logra cuando el contenedor invoca un constructor de clase con varios argumentos, cada uno de los cuales representa una dependencia de otra clase.

2 Inyección de dependencia basada en Setter

La DI basada en Setter se logra mediante los métodos de establecimiento de llamadas de contenedor en sus beans después de invocar un constructor sin argumentos o un método de fábrica estático sin argumentos para instanciar su bean.

Puede mezclar tanto DI basada en constructor como basada en Setter, pero es una buena regla general utilizar argumentos de constructor para dependencias obligatorias y establecedores para dependencias opcionales.

El código es más limpio con el principio DI y el desacoplamiento es más efectivo cuando se proporcionan objetos con sus dependencias. El objeto no busca sus dependencias, y no conoce la ubicación o clase de las dependencias, más bien Spring Framework se ocupa de todo.

Espero eso ayude.

La imagen habla más de 100 palabras. Aquí hay un video sobre Spring Framework. Vaya a la marca de las 02:00 minutos si desea ver un ejemplo rápido.

Buena suerte.