En algún lugar que leí, Spring ofrece comodidad sobre la configuración. Pero la gente de Spring está introduciendo tantos cambios en la configuración, que ahora estoy realmente confundido al usar la configuración xml o la anotación.
Me gustaría que alguien sugiera una metodología segura o una regla general al usar xml y anotaciones.
Ejemplos en SO para mostrar que muchos principiantes como yo se confunden con la configuración.
-
No parece captar la funcionalidad detrás
<context:annotation-config>y<context:component-scan>.Por lo que he leído, parecen manejar diferentes anotaciones (@Required, @Autowired, etc. vs @Component, @Repository, @Service, etc.) pero también por lo que he leído registran las mismas clases de postprocesador de beans.
Para confundirme aún más, hay un
annotation-configatributo en<context:component-scan>... -
Todavía tengo la etiqueta de escaneo de componentes:
<context:component-scan base-package="com.mycompany.maventestwebapp" />pero también tengo otra etiqueta (que parece tener una tarea similar), esta:
<annotation-driven />¿Cuál es la diferencia entre estas dos etiquetas? Otra cosa "extraña" es que el ejemplo anterior (que no usa la etiqueta basada en anotaciones) es muy similar al proyecto creado por STS utilizando el proyecto Spring MVC Template, pero si elimino la etiqueta basada en anotaciones de su configuración archivo el proyecto no se ejecuta y me da el siguiente error: HTTP Estado 404 - ...
Spring 3.2 ya no necesita cglib para proxy, pero las versiones inferiores usan cglib. Una cita del blog de springsource
Para generar tales proxies, Spring usa una biblioteca de terceros llamada cglib. Lamentablemente, este proyecto ya no está activo. En Spring 3.2, es muy probable que Spring use Javassist en su lugar por defecto.
¿Son suficientes para sugerir que Spring is Confusion sobre la configuración?
Respuestas:
Spring tiene como objetivo proporcionarle un marco en el que haya "convención sobre la configuración". Sin embargo, la realidad es que las aplicaciones Spring necesitan una cierta cantidad de configuración.
En Spring 2.5.xy versiones anteriores, el idioma común era proporcionar esta configuración a través de XML. Con Spring 3.0+, la forma idiomática es usar anotaciones (algo que Java EE6 / 7 también fomenta).
Como nota al margen, puede ser divertido (¿triste?) Ver una entidad JPA anotada, es bastante fácil agregar 4+ anotaciones a un solo campo ...
fuente
Debe especificar el esquema XML de dónde proviene.
Lo más probable es que esté en el contexto de la estrategia de manejo de transacciones JPA al definir el Administrador de transacciones (consulte 9.5.6. Uso de @Transactional en los documentos de Spring)
Cuando define el manejo de transacciones impulsado por anotaciones, Spring AOP crea automáticamente aspectos para que su método inicie (o verifique la transacción existente) antes de invocar un método y luego confirmar (o revertir en caso de excepción) después de que la invocación del método haya finalizado.
fuente
Descubrí que las anotaciones basadas en la creación de IoC / Bean son útiles cuando tienes una implementación de singleton pero es posible que necesites cambiarla.
En contraste con una situación en la que puede necesitar reutilizar un bean repetidamente con diferentes clases / instancias dependientes.
En esos casos, declaro el bean en config y generalmente hago la inyección del constructor de cualquier dependencia que necesite. Luego, en la clase que usará dichos frijoles I
@Autowirey luego@Qualifier(""), así es como se supone que funcionan las fábricas.Un singleton es un método de fábrica que solo devuelve 1 resultado. Cuando esto no se aplica fácilmente, es cuando necesitas mezclarlo.
En cuanto al uso de escaneo de componentes versus no, esto realmente está sujeto a los criterios anteriores y al buen juicio. En general, soy muy explícito sobre el escaneo de componentes del paquete. De esa manera, puedo crear un contexto de aplicación diferente para las pruebas donde puedo burlarme de las dependencias externas (como un db) mientras sigo probando el resto de mi configuración de IoC.
Además, no tengo
@Componentningún código de biblioteca en mi proyecto. Nunca se sabe cuándo / cómo necesitará usar un bean allí y si lo@Componenthace, puede recogerlo accidentalmente en un escaneo y limitar su reutilización. Para estos casos, generalmente tengo un contexto de aplicación definido en la biblioteca con algunos valores predeterminados útiles de declaración de beans que mi proyecto principal PUEDE incluir con las importaciones en su contexto de aplicación.No hay religión aquí. Solo experiencias para transmitir
fuente
Spring ofrece opciones, originalmente solo existía el cableado basado en xml. Posteriormente se agregó el cableado basado en anotaciones.
Ahora es posible (y muchas personas lo hacen) usar una combinación de ambos.
Hay una amplia documentación incluida con Spring y / o descargable desde el sitio web de springsource. Hay capacitación profesional (nunca lo hice, no puedo dar fe de ello), y algunos buenos libros (me gusta APress 'Pro Spring, elige la versión correcta para la versión de Spring que estás empleando).
fuente