Separación de niveles de presentación y negocios con Spring

Question

En mi proyecto recién terminado, estaba trabajando para que las transacciones distribuidas funcionen.

Implementamos esto usando el Arjuna Transaction Manager de JBoss y los límites de transacción declarativos de Spring.

Nuestra secuencia de solicitud se veía así:

browser -> secured servlet -> 'wafer-thin' SLSB -> spring TX-aware proxy -> request-handler POJO

Lo que esto significa es que teníamos un WAR para servir a nuestro servlet seguro y un EAR para servir a nuestro SLSB.

Nuestro SLSB tenía un bloque de inicializador estático para arrancar el contexto de nuestra aplicación Spring.

No me gusta la combinación de tecnologías, pero me gusta la separación de los niveles de presentación y de negocios, que podrían residir en diferentes ubicaciones físicas.

¿Me interesaría saber qué proponen otros para separar los niveles al usar Spring?

Answer 1

Requerir un servidor de aplicaciones EJB3 solo para un SLSB que es una fachada no me parece que valga la pena. No hay ninguna razón por la que no pueda simplemente eliminar eso y hacer que su servlet funcione directamente con Spring. Puede agregar ContextLoaderListener a WAR para cargar su ApplicationContext y luego WebApplicationContextUtils para acceder a él. Alternativamente, podría usar SpringMVC, Struts u otras tecnologías web si necesita hacer más de lo que el Servlet por sí solo permitirá.

Answer 2

Un enfoque bastante típico es definir un nivel web, un nivel de servicio y un nivel DAO, y adjuntar semántica transaccional al nivel de servicio. El nivel de servicio puede ser un grupo de POJO con anotaciones @Transactional, por ejemplo. El nivel web puede ser controladores Spring Web MVC. En este enfoque, el nivel web esencialmente está adaptando el nivel de servicio a HTTP. Buena separación y sin necesidad de SLSB aquí.

Sin embargo, un área de debate es con respecto a los objetos de dominio, como Employee o PurchaseOrder o lo que sea. Estos niveles de aplicación abarcan y una cosa que parece estar sucediendo con las anotaciones es que los objetos de dominio obtienen anotaciones que están vinculadas a niveles específicos. Por lo tanto, es posible que tenga anotaciones ORM aquí, pero luego use el mismo objeto de dominio como un bean de respaldo de formulario como una forma de evitar clases paralelas de dominio / objeto de formulario. Algunas personas se oponen a eso porque viola la separación arquitectónica de las preocupaciones.