La primavera @Autowired uso

Question

¿Cuáles son los pros y los contras de la utilización de @Autowired en una clase que va a estar conectado por la Primavera?

Solo para aclarar, estoy hablando específicamente de la @Autowired anotación, no auto-cableado en XML.

Probablemente yo simplemente no lo entiendo, pero a mí me parece casi un anti-patrón - las clases comienzan a ser conscientes de que están atados a una DI marco, en lugar de ser POJOs.Tal vez yo soy un masoquista, pero me gusta tener el externo de configuración XML para el frijol, y me gustaría tener explícita cableados, así que sé exactamente lo que está cableada donde.

Answer 1

Durante mucho tiempo he creído que hay un valor en tener un "centralizado, declarativas, de configuración" como los archivos xml que todos estamos acostumbrados a utilizar.Entonces me di cuenta de que la mayoría de las cosas en los archivos no configuración - nunca fue cambiado en cualquier lugar después de que el desarrollo, nunca.Entonces me di cuenta de que "centralizado" sólo tiene valor en muy pequeños sistemas - sólo en sistemas pequeños que nunca vas a ser capaz de asimilar un archivo de configuración como un todo.Y lo que es realmente el valor de la comprensión del cableado como un todo, cuando en el mismo "cableados" son en su mayoría duplicado por las dependencias en el código?Así que lo único que he mantenido es meta-datos (anotaciones), que es todavía de tipo de declarativo.Estos nunca cambiar en tiempo de ejecución y que están nunca "configuración de datos" que alguien va a cambiar sobre la marcha, así que creo que lo mantiene en el código es agradable.

Yo uso completo de auto-cableado tanto como puedo.Me encanta.No voy a volver al estilo antiguo, de primavera a menos amenazado a punta de pistola.Mis razones para preferir totalmente @Autowired han cambiado a lo largo del tiempo.

De momento creo que la razón más importante para el uso de autowiring es que hay uno menos de abstracción en su sistema para seguir la pista de.El "bean name" ha desaparecido.Resulta que el bean nombre sólo existe porque de xml.Así que una capa completa de resumen indirections (donde alambre de frijol nombre "foo" en frijol "bar") se ha ido.Ahora me alambre de la "Foo" de la interfaz en mi bean directamente, y la aplicación es el elegido por el tiempo de ejecución de perfil.Esto me permite trabajar con código cuando el trazado de las dependencias y de las implementaciones.Cuando veo a un autowired dependencia en mi código me puede simplemente pulse el botón de "ir a la aplicación" llave en mi IDE y sale la lista de implementaciones.En la mayoría de los casos sólo hay una aplicación y me voy directamente a la clase.No puede ser mucho más sencillo que eso, y siempre sé exactamente ¿qué aplicación está siendo utilizada (afirmo que el contrario está más cerca de la verdad con xml cableado - es curioso cómo su perspectiva cambia!)

Ahora se podría decir que es sólo una muy simple capa, pero cada capa de abstracción que añadimos a nuestros sistemas aumentar de la complejidad.Yo realmente no creo que el xml cada vez añadido ningún valor real a cualquier sistema con las que he trabajado.

La mayoría de los sistemas que he trabajo con sólo han uno configuración de la producción entorno de tiempo de ejecución.Puede haber otras configuraciones de prueba y así sucesivamente.

Yo diría que el pleno autowiring es el ruby-on-rails de la primavera:Abraza la noción de que hay una normal y patrón de uso común que la mayoría de los casos de uso siga.Con el XML de configuración permiso de un montón de coherente/incoherente configuración de uso que puede o no puede ser la intención.He visto mucho de configuración xml ir por la borda con inconsistencias - ¿refactorizado junto con el código ?No pensamiento.Son las variaciones de allí por una razón?Por lo general no.

Casi no uso de calificadores en nuestra configuración, y encontrar otras maneras de resolver estas situaciones.Esta es una clara desventaja", nos encontramos con:Hemos ligeramente cambiado la forma de código para interactuar más suave con autowiring:Un cliente repositorio ya no implementa el genérico Repository<Customer> la interfaz pero hacemos una interfaz CustomerRepository que se extiende Repository<Customer>.A veces también hay un truco o dos cuando se trata de la creación de subclases.Pero por lo general sólo nos apunta en la dirección de los más fuertes de escribir, lo que me parece es casi siempre una mejor solución.

Pero sí, estás atando a un estilo particular de DI que la mayoría de la primavera no.Nosotros incluso no hacer públicas las incubadoras para las dependencias alguna más (por Lo que se podría argumentar que estamos +1 en la encapsulación/ocultar información departamento) todavía Tenemos algo de xml en nuestro sistema, pero el xml básicamente sólo contiene las anomalías.Completa autowiring que se integra muy bien con xml.

Lo único que necesitamos ahora es para el @Component, @Autowired y el resto para ser incluido en un JSR (como JSR-250), por lo que no tiene que atar en la primavera.Esta es la forma en que las cosas han estado ocurriendo en el pasado (el java.util.concurrent cosas que viene a la mente), para no ser totalmente sorprendido si esto sucediera de nuevo.

Answer 2

Para mí, esto es lo que me gusta / no me gusta de Spring y el cableado automático.

Pros:

• El cableado automático elimina la configuración XML desagradable.
• Anotaciones mucho más fáciles de usar que le permiten inyectar directamente usando campos, métodos de establecimiento o constructores. También le permite anotar y 'calificar' sus granos inyectados.

Contras:

• El uso del cableado automático y las anotaciones lo hacen dependiente de las bibliotecas de Spring donde, al igual que con la configuración XML, puede elegir ejecutar con o sin Spring. Como dijiste, te atas a un marco DI.
• Al mismo tiempo, me gusta poder 'calificar' los beans, para mí esto hace que el código sea realmente desordenado. Si necesita inyectar el mismo bean en varios lugares, he visto el mismo nombre de cadena repetido por todas partes. Para mí, esto parece tener el potencial de errores.

Empecé a usar el cableado automático casi exclusivamente en el trabajo porque de todos modos dependemos tanto de la integración de Spring que el problema de dependencia es discutible. Trabajé en un proyecto Spring MVC que utilizaba mucho el cableado automático y era un poco difícil de entender.

Creo que el cableado automático es un gusto adquirido, una vez que te acostumbras te das cuenta de cuán poderoso, fácil y mucho menos dolor de cabeza es trabajar que la configuración XML.

Answer 3

Estamos cambiando de @Autowire a la configuración XML en nuestro gran proyecto. El problema es un rendimiento de arranque muy bajo. El escáner de cableado automático carga todas las clases de la ruta de clase de búsqueda de cableado automático, por lo que muchas clases se cargan con entusiasmo durante la inicialización de Spring.

Answer 4

Ha habido muy poca discusión sobre el cambio de entornos. La mayoría de los proyectos en los que he trabajado fue un problema real para inyectar dependencias dependiendo del entorno en el que estamos trabajando. Con la configuración xml es bastante sencillo con Spring EL, y no conozco ninguna solución agradable con anotaciones. Acabo de descubrir uno:

    @Value("#{${env} == "production" ? realService : dummyService}")
    private SomeService service;

Debería estar funcionando, pero no es una buena solución en mi humilde opinión.

Answer 5

He cambiado a @Autowire. Mantener la configuración XML en cualquier cosa que no sea un proyecto pequeño se convirtió en una tarea en sí misma y la comprensión se degradó rápidamente.

IntelliJ proporciona un buen soporte (no perfecto) para las anotaciones de Spring.

Answer 6

Mi opinión sobre este tema es que, la configuración xml reduce la claridad del código, especialmente en sistemas grandes.

Las anotaciones como @Component empeoran aún más las cosas. Dirige a los desarrolladores a hacer que los objetos sean mutables, ya que las dependencias ya no se pueden hacer definitivas, dado que se deben proporcionar los constructores predeterminados. Las dependencias deben ser inyectadas a través de setter público o no controladas a través de @Autowired. [aún peor, la inyección de dependencias se ve comprometida con clases que crean instancias de sus dependencias, ¡todavía veo esto en el código recién escrito!]. Por no controlado quiero decir, en sistemas grandes, cuando hay disponibles múltiples implementaciones (o hijos) del tipo, se involucra mucho más entender cuál de las implementaciones era @Autowired, una complejidad que hace que la investigación de errores sea mucho más difícil. También significa que, supuestamente tiene un perfil para el entorno de prueba y otro para la producción, sus errores de producción solo sucederán cuando duela más, en la producción, en lugar de poder detectar los errores en el entorno de prueba, o incluso mejor, en tiempo de compilación!

Me quedo en el punto medio donde declaro mi (s) clase (s) de configuración (configuración de Spring basada en Java usando @Configuration)

Declaro todos mis beans explícitamente en las clases de configuración. Solo uso @Autowired en la (s) clase (s) de configuración, el propósito es limitar la dependencia de Spring a la (s) clase (s) de configuración

La @Configuration reside en un paquete específico, ese es el único lugar donde se ejecuta el escaneo de primavera. (Eso acelera sustancialmente el tiempo de inicio en grandes proyectos)

Me esfuerzo por hacer que todas mis clases sean inmutables, especialmente el objeto de datos, JPA, Hibernate y Spring, así como muchas bibliotecas de serialización parecen socavar esto. Me alejo de cualquier cosa que me obligue a proporcionar setters, o elimine la palabra clave final de mi declaración de propiedad.

La reducción de las posibilidades de cambiar los objetos después de su creación, reduce sustancialmente los errores en el sistema grande, así como el tiempo para encontrar un error cuando existe uno.

También parece que obliga al desarrollador a diseñar mejor la interacción entre las diferentes partes del sistema. Los problemas y errores se vuelven cada vez más errores de compilación, lo que reduce el tiempo perdido y mejora la productividad.

Answer 7

Aquí hay algo de experiencia
Profesionales

• Hace más fácil la configuración porque podemos usar la anotación @Autowire
• No quiero usar métodos de establecimiento, por lo que la clase será más limpia

Cons

• Acoplarse al archivo xml aunque estemos usando DI
• Implementación difícil de encontrar (pero si estás usando buenas ideas como intellij seguro puedes deshacerte de esto)

Debido a mis experiencias personales, no utilicé mucho la anotación @AutoWire, sino en casos de prueba.

Answer 8

Realmente me encanta escribir con anotaciones, en lugar de XML. Según el manual de Spring y las últimas versiones, XML y Annotation lograron el mismo resultado.

Esta es mi lista

Pro:

• Eliminar línea inútil de xml
• Simplifique la depuración del código: cuando abre una clase, puede leer lo que tiene en la clase
• ¿Desarrollo más rápido, un proyecto con 400 o más líneas de XML es legible?

Contras:

• No es una implementación estándar de Java, pero puede cambiar para usar @Inject, que es una API estándar de Java, por lo que el bean sigue siendo un Pojo
• No se puede usar simplemente en todas partes, conexión db, etc., pero es solo una opinión, prefiero tener un lugar donde leer toda la configuración.

Answer 9

Según tengo entendido, @Autowired es el mejor para usar mientras se hace referencia a la referencia de interfaz y utiliza sus funciones de anulación, pero solo encuentro un problema con esto es que a veces se asigna a nulo en tiempo de ejecución.