2010-07-27 27 views
18

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, orden de mostrar procesada 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ándo tiene sentido utilizar Spring WebFlow sobre Spring MVC? ¿Cuál debería ser el proceso de toma de decisiones con respecto al uso de Spring WebFlow?

Respuesta

6

Si tiene una aplicación web que tiene algún proceso de solicitud. 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 la transición a diferentes conjuntos de procesos muy bien.

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, SWF es bueno para usar.

2

Un problema que el flujo de web resuelve eficientemente es que separa claramente (o al menos hace que sea muy difícil mezclar) la lógica de negocio 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 comiences a usar webflow en gran medida, te encontrarás escribiendo una gran cantidad de archivos xml (ya que en webflow especificas todos los flujos en archivos xml). Esto es casi un factor decisivo para mí personalmente.

+0

Acepto que el xml es muy engorroso, pero la alternativa es incluso mucho más (escribir su propia lógica de flujo con java). He visto a gente intentar hacerlo antes de que el flujo web estuviera disponible y es una pesadilla para mantener. –

4

Lo que personalmente me gusta en WebFlow la mayoría son 2 cosas:

  1. Capacidad para heredar los flujos y ver los estados. Esto es bastante útil cuando tiene algunos aspectos lógicos comunes que desea compartir entre diferentes partes de su aplicación. Por ejemplo, tiene una 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 fina.
  2. Potente marco de prueba. Es posible cubrir casi todos los aspectos de su lógica de flujo en pruebas unitarias. Puede emular muchas cosas programáticas, tales como disparos de acción, las transiciones de una vista a otra, la persistencia de flujo y manejo y así sucesivamente

Lo que no me gusta es la inconsistencia y la mala 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, webflow casi lo forzará a separar su lógica en diferentes flujos web, y esto es bueno, creo.

1

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

  1. Spring MVC no tiene un mecanismo incorporado para el control de la sesión en varias pestañas en el mismo navegador.
  2. Manejar el navegador backs es más fácil en SWF que MVC.