Integración de la capa de negocio

Spring no cumple el estándar JEE

El problema mas común de integración es que dado el carácter invasivo de la política de inyección de dependencias de spring , se altera el ciclo de vida de Java Server Faces, afectando su rendimiento y funcionalidad e incitando al cambio de un framework web reconocido y recomendado por el estándar como JSF. Por otra parte no forma parte de ningún estándar con Spring MVC

Integración de varios servicios específicos

Spring necesita integrar varios servicios para cumplir con las funcionalidades de la capa. Los servicios que requiere integrar:

• Requiere integración de un framework de mapeo OR
• Requiere de configuración de un servicio adicional para seguridad llamado SpringSecurity
• Requiere la adición de productos como terracota que no pertenecen a spring para ofrecer el servicio de cluster, es muy complejo especificar la granularidad
• Require la configuración adicional de un modulo para poder exponer webservices

Problemas con el despliegue

La implementación de una capa de negocio con tecnologías Spring requiere de la integración de varias tecnologías de diversos fabricantes, en este esquema se descarta la posibilidad de hacer un despliegue de componentes distribuido, para esto se necesita agregar otro producto y por lo tanto, una capa adicional de complejidad que puede afectar seriamente el rendimiento del sistema . Una visión gráfica de lo descrito:

Incremento del código y de archivos fuente con el uso de Spring

La configuración de los componentes Spring no resulta compleja, mediante el uso de archivos xml de configuración. Sin embargo se genera un mayor numero de clases, las cuales no son complejas, pero al ir creciendo el sistema, dará como resultado un numero entre tres y cuatro veces mayor de clases para una funcionalidad básica como lo es guardar una entidad en una base de datos.

Integración con JSF

Es de amplio conocimiento que Spring interrumpe el ciclo de vida de JSF. Si se instancia un nuevo managed bean, todas sus dependencias están en null. Esto presenta un gran obstáculo en el desarrollo JSF, ya que no se puede acceder a ningún objeto de negocio en el constructor, esto impide acceder a bases de datos o realizar procesamiento de lógica de negocio previo a la carga de la página

La única solución a esto es inyectar las dependencias de forma manual, pero esta actuación conlleva el problema que se inyecta una vez de forma manual, mediante el Face-Config de configuración, y luego Spring inyecta nuevamente esta dependencia lo que afecta directamente el rendimiento.

Además, toda clase se define como serializable, para que cuando se instancie el servlet en el contenedor de servlet por primera vez, al acceder por segunda, tercera , cuarto..... a la misma instancia se debería de tomar la instancia de la clase, con los valores que se tuviesen en el ese momento, no inicializándose de nuevo la clase. El problema es que al no poder inicializar el contexto en el constructor, se debe de crear un nuevo método que será cargado al comienzo de la renderización de la pantalla, pasándose la responsabilidad de la nueva instanciación de la clase (realmente es la misma instancia anterior) a la capa de presentación.

// En la página xhtml:
<h:outputText value="#{editorCatalogacionAction.init}" />

// En el action asociado a dicha página:
public EditorCatalogacionAction() {
        formDatos = new RegistroBibliograficoDetalleForm();
}

Como vemos en el constructor, lo único que se hace es inicializar el formulario que almacena los valores de la interfaz gráfica. Esta variable será inyectada por dependencia de Spring en el Face-Config

@SuppressWarnings("unchecked")
    public String getInit() {

              (1)  formDatos.setPlantilla(nameTemplate);
                cambiarPlantilla(null);
            }

        }
        return "";
    }

Como se observa, mientras que en el contructor la línea (1) hubiese sido imposible de ejecutar porque formDatos hubiese sido siempre null (aún no se ha cargado), debemos de delegar esta ejecución a un método ESPECIAL, fuera del constructor.

Tamaño de los proyectos

Dada las características de Spring, cuando un proyecto se convierte en un proyecto de gran tamaño Spring tiene ciertos problemas de mantenimiento debido especialmente a la gran cantidad de código que genera. Esto implica una dificultad mayor y un esfuerzo considerable en la detección y comprensión en el código.