Spring context files organization and best practices

Question

Hemos comenzado a usar Spring framework en mi proyecto. Después de familiarizarnos con las características básicas (IoC), también comenzamos a usar Spring Aop y Spring Safety.

El problema es que ahora tenemos más de 8 archivos de contexto diferentes y creo que no pensamos lo suficiente para la organización de esos archivos y sus roles. Se presentaron nuevos archivos a medida que el proyecto evolucionó. Tenemos diferentes archivos de contexto para: metadatos, aop, autorización, servicios, recursos web (es una aplicación RESTful). Entonces, cuando un desarrollador quiere agregar un nuevo bean, no siempre está claro en qué archivo debe agregarlo. Necesitamos metodología.

La pregunta:

¿Hay una mejor práctica para la organización de los archivos de la primavera?

¿Los archivos de contexto deben encapsular capas (DAL, Business Logic, Web) o casos de uso? o fluye?

Answer 1

Si todavía está razonablemente temprano en el proyecto, le aconsejaría encarecidamente que observe la configuración basada en anotaciones. Después de convertir a anotaciones, solo tenemos 1 archivo xml con definiciones y es realmente bastante pequeño, y este es un proyecto grande. La configuración impulsada por la anotación pone el foco en su implementación en lugar del xml. También elimina más o menos la capa de abstracción bastante redundante que es el nombre de "bean" de primavera. Resulta que el nombre del bean existe principalmente porque de xml (El nombre del bean todavía existe en la configuración de la anotación, pero es irrelevante en la mayoría de los casos). Después de hacer esto, active un gran proyecto, todos están 100% de acuerdo en que es lote mejor y también tenemos evidencia bastante decente de que es un entorno más productivo.

Realmente recomendaría cualquier persona que use la primavera para cambiar a anotaciones. Es posible mezclarlos también. Si necesita asesoramiento de transición, supongo que es fácil preguntar por SO;)

Answer 2

Los archivos de contexto de primavera contienen definiciones de beans, por lo que creo que es mejor seguir el principio de OO y estructurarlos de la misma forma que estructura las clases en paquetes. Por lo general, creamos paquetes para encapsular un conjunto de clases que trabajan juntas para resolver un problema específico. Un paquete generalmente encapsula una capa horizontal (capa de base de datos, middleware, lógica de negocio o parte de ellos). Hay ocasiones en que un paquete contiene clases que corresponden a una capa horizontal (caso de uso o flujo como usted ha mencionado). En general, recomendaría crear un archivo de contexto para cada paquete o conjunto de paquetes. Cuando agrega un nuevo bean, agréguelo al archivo de contexto que corresponde al paquete de la clase.

Por supuesto, esta no debería ser una regla muy estricta, ya que podría haber casos en los que sería beneficioso seguir otra práctica.

Answer 3

Me parece que los descompongo por capas.

Cuando escribo pruebas unitarias para cada capa anulo el contexto de producción con los valores pertinentes para las pruebas.

Answer 4

Romper la configuración en archivos separados me resulta útil en términos de prueba. En un proyecto pequeño, pondré la configuración de Spring Security en "securityContext.xml" y el resto de mis beans en "applicationContext.xml". Luego, al ejecutar las pruebas de integración, es fácil habilitar o deshabilitar la seguridad de manera simple al elegir si incluir securityContext.xml. Esto casi se asemeja al AOP de una manera, ya que agrega más funcionalidad a la aplicación al elegir si desea incluir archivos particulares.

Answer 5

Comience con applicationContext.xml y sepárelo cuando haya muchos frijoles que tengan algo en común.

Para darle una idea de una posible configuración, en la aplicación que estoy trabajando actualmente, esto es lo que tengo en el servidor:

• applicationContext.xml
• securityContext.xml
• schedulingContext .xml
• dataSourcecontext.xml
• primavera-WS-servlet.xml (web Services primavera granos relacionados)

Para clientes de GUI, dado que este proyecto tiene varios, hay una carpeta con archivos de contexto compartidos, y además, cada cliente tiene su propia carpeta de contexto. archivos de contexto en común:

• sharedMainApplicationContext.xml
• sharedGuiContext.xml
• sharedSecurityContext.xml archivos

App-específicos:

• mainApplicationContext.xml y
• guiContext .xml y
• commandsContext.xml (estructura de menú)
• sharedBusinessLayerContext.xml (frijoles para la conexión con el servidor)

Answer 6

sip - split en papeles similares para los granos de las mismas. En cuanto a las anotaciones, creo que "pueden" tener un pequeño papel que desempeñar, tal vez con definiciones de transacción, pero de lo contrario, solo obligan para siempre tu código y podrías agregar referencias de primavera (o de cualquier otro tercero) directamente en todas partes. Para mí, anotaciones = atajo y deuda técnica. No son configurables externamente, por lo que no es trivial volver a cablear, ni desenvolver su código, y limita la reutilización. Un bean determinado queda para siempre atascado con sus dependencias anotadas y su configuración, de modo que no puede ser utilizado por múltiples proyectos/procesos simultáneamente con diferentes conexiones y configuraciones. solo mis 2 centavos.

Answer 7

Seguiría las recomendaciones de la primavera y colocaría los archivos de contexto en META-INF/spring como se describe en el Spring Roo documentation. En general, recomendaría probar roo y seguir su estructura y diseño de proyecto.

Ejemplo

src/ 
+-- main/ 
| +-- java/ 
| \-- resources/ 
|  +-- META-INF/ 
|  | \-- spring/     ‹ normal spring context files 
|  |  +-- context.xml 
|  |  \-- context-services.xml 
|  \-- other files 
| 
+-- test/ 
| +-- java/ 
| \-- resources/ 
|  +-- META-INF/ 
|  | \-- spring/     ‹ context files for testing 
|  |  +-- context-test.xml 
|  |  \-- context-dao-test.xml 
|  \-- other files 
| 
\-- pom.xml 

XML Spring vs anotaciones

Hay muchos buenos artículos sobre el tema, pero me gustaría para romper un error muy común, debido a que ambos enfoques tienen sus méritos : Si desea separar la configuración de la implementación real, es más fácil con XML, pero puede lograr lo mismo con las anotaciones, como krosenvold said.Sin embargo, cuando se usan archivos de configuración XML, los nombres de los beans solo son necesarios, si el bean tiene que ser referenciado directamente. Siempre puede usar auto-wiring por nombre o por tipo.

Lo único importante es que debe mantenerse constante durante todo el proyecto o, cuando sea posible, en todos los proyectos de su empresa.