tutorial objects mvc español java spring web-applications spring-mvc spring-webflow

java - objects - ¿Cuándo tiene sentido usar Spring WebFlow sobre Spring MVC?



spring web flow tutorial español (4)

He utilizado MVC y SWF. Personalmente prefiero SWF sobre MVC debido a las siguientes dos razones sólidas:

  1. Spring MVC no tiene un mecanismo incorporado para el control de sesiones en varias pestañas en el mismo navegador.
  2. El manejo de los navegadores es más fácil en SWF que en MVC.

Spring MVC se ha convertido en un marco muy popular para crear aplicaciones web empresariales. Cualquier aplicación web compleja tiene ciertos flujos que deben codificarse, incluidos algunos flujos condicionales (es decir, mostrar el orden procesado si la información de la tarjeta de crédito era correcta o errores de validación si algo no se ingresó correctamente).

¿Cuándo tiene sentido usar Spring WebFlow sobre Spring MVC? ¿Cuál debería ser el proceso de toma de decisiones con respecto al uso de Spring WebFlow?


Lo que personalmente me gusta en webflow más son 2 cosas:

  1. Habilidad para heredar flujos y estados de vista. Esto es bastante útil cuando tiene algunos aspectos lógicos comunes que desea compartir entre diferentes partes de su aplicación. Por ejemplo, tiene la lógica CRUD que desea abstraer en un flujo separado y luego permitir que los flujos secundarios hereden esta lógica. Cada flujo puede tener entrada y salida, por lo que su lógica puede ser muy precisa.
  2. Marco de prueba de gran alcance. Es posible cubrir casi todos los aspectos de su lógica de flujo en pruebas unitarias. Puede emular muchas cosas programáticas, como disparos de acciones, transiciones de una vista a otra, manejo de la persistencia del flujo, etc.

Lo que no me gusta es la inconsistencia y la poca compatibilidad con versiones anteriores de las versiones más recientes. Por ejemplo, el último webflow 2.1 no es compatible con JSF 1.x jira . También hay numerosos problemas con la integración con Spring Security. Por ejemplo, en Spring Security 3.x, simplemente cambiaron algunos nombres de paquetes. En general, como mencionó Sasi, el flujo web casi obligará a separar su lógica en diferentes flujos web, y creo que es bueno.


Si tienes una aplicación web que tiene algún proceso de aplicación. Por ejemplo, si tiene algún tipo de proceso de registro, un botón puede ir a una página mientras que otro puede ir a una página diferente. Spring Webflow puede manejar muy bien la transición a diferentes conjuntos de procesos.

Básicamente, si alguna parte de su aplicación está vinculada y las páginas dependen unas de otras durante el curso de una ejecución, es bueno usar SWF.


Un problema que el flujo web resuelve de manera eficiente es que separa claramente (o al menos hace muy difícil mezclar) la lógica empresarial de su lógica de control.
Estoy de acuerdo con @John en los casos de uso, pero me gustaría señalar que una vez que empieces a usar el flujo de web en gran medida, te encontrarás escribiendo muchos archivos xml (ya que en el flujo de web especificas todos los flujos en archivos xml). Esto es casi un factor decisivo para mí personalmente.