Buenas prácticas en la construcción de la capa de negocio con Spring

Se recomienda modularizar aquellos aspectos o servicios que sean utilizados repetidas veces en diferentes componentes de un sistema. De esta forma se podrán aplicar de manera declarativa a los componentes que los precisen.

Se recomienda crear las inyecciones de dependencias por métodos "setters", en lugar de hacerlo mediante los constructores, ya que es más flexible, sobre todo cuando la clase tiene muchas propiedades y la mayoría son opcionales.

Se recomienda declarar beans para cada DAO, así como para implementar la fachada y la factoría de sesiones que usan los DAOs.

Las aplicaciones deben seguir la jerarquía de excepciones de Spring para su tratamiento en la capa de negocio. Para realizar la conversión entre las excepciones nativas y la jerarquía propia de Spring será necesario declarar el siguiente bean:

<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>

Se recomienda que todos los servicios hereden de una clase común, para así poder aplicar comportamientos genéricos sin impacto.

Se recomienda altamente no incluir negocio en los aspectos.

A la hora de añadir las bibliotecas de Spring en nuestro proyecto,tenemos que asegurarnos que, si se tiene el JAR spring.jar, no se tienen que añadir también las bibliotecas spring-aop.jar y spring-dao.jar, ya que ambas están contenidas en la primera.

Se deben utilizar las formas abreviadas para la configuración ya que son más fáciles de leer, dado que transforma el valor de los elementos hijos en atributos del elemento padre, lo que proporciona archivo XML mucho más claro.

Se debe utilizar el atributo type para los argumentos de los constructores ya que es más fácil de leer y evita errores. Sólo se utilizará el atributo index para resolver los problemas de ambigüedad cuando un constructor tiene más de un argumento del mismo tipo o cuando se utiliza el atributo value para asignar el valor.

Se debe utilizar el mecanismo de pseudo-herencia que ofrece Spring para reducir la duplicación de información en los archivos de configuración. Una definición de un bean hijo puede heredar la información de configuración de sus padres, los cuales sirven como una plantilla para estos.

La integración de distintos archivos de configuración se hará a través del ApplicationContext ya que es mucho más flexible que hacerlo dentro del XML utilizando imports, haciendo que la configuración XML sea más fácil de manejar.

Debemos utilizar ids como identificadores de los beans ya que, aunque no aumentan la legibilidad, pueden permitir que el analizador XML valide las referencias de los beans. Se usarán nombres como identificadores de beans si los ids no pueden ser utilizados debido a alguna restricción XML IDREF. Esta restricción dice que los ids deben comenzar con una letra (o alguno de los pocos caracteres de signo de puntuación permitidos en la especificación XML) seguido de letras, dígitos, guiones, guiones bajos, dos puntos o punto.

Se recomienda utilizar las validaciones de dependencias en desarrollo, ya que es muy útil cuando todas las propiedades de un bean deben ser asignadas explícitamente (o por autowiring).

Se recomienda agregar un encabezado en los archivos de configuración que englobe a los beans definidos en el archivo. Además, se recomienda usar identificadores y nombres descriptivos en vez de utilizar comentarios en los archivos de configuración.

No se debe abusar de la creación de objetos a través del motor de inyección de dependencias ya que los archivos de configuración pueden sobrecargarse mucho si no se controla bien el crecimiento de los beans definidos, haciéndolos muy complicados.