Cuándo usar Windows Workflow Foundation?

Question

Algunas cosas son más fáciles de implementar a mano (código), pero algunas son más fáciles a través de WF. Parece que WF se puede usar para crear (casi) cualquier tipo de algoritmo. Entonces (teóricamente) puedo hacer toda mi lógica en WF, pero probablemente sea una mala idea hacerlo para todos los proyectos.

¿En qué situaciones es una buena idea usar WF y cuándo las cosas serán más difíciles de lo que deben ser? ¿Cuáles son los pros y los contras/costes de WF frente a la codificación manual?

Answer 1

Es posible que necesite WF sólo si alguna de las siguientes son verdaderas:

1. tiene un proceso de larga duración.
2. Tiene un proceso que cambia con frecuencia.
3. Desea un modelo visual del proceso.

Para más detalles, ver post de Pablo Andrés: What to use Windows Workflow Foundation for?

Por favor, no confunda o se relacionan con WF programación visual de cualquier tipo. Está mal y puede llevar a decisiones de arquitectura/diseño muy malas.

Answer 2

El código generado por WF es desagradable. El valor que aporta WF está en la representación visual del sistema, aunque todavía tengo que ver algo (6-7 proyectos en funcionamiento ahora con WF con los que he estado involucrado) donde no hubiera preferido un proyecto codificado a mano más simple .

Answer 3

Personalmente, no estoy vendido en WF. Su utilidad no era tan obvia para mí como otras nuevas tecnologías de MS, como WPF o WCF.

Creo que WF se usará mucho en aplicaciones comerciales en el futuro, pero no tengo planes de usarlo porque no parece ser la herramienta adecuada para el trabajo de mis proyectos.

Answer 4

La razón principal que he encontrado para utilizar la base de flujo de trabajo es cuánto te saca de la caja en términos de seguimiento y persistencia. Es muy fácil poner en marcha el servicio de persistencia, lo que brinda confiabilidad y distribución de carga entre varias instancias y hosts.

Por otro lado, al igual que las aplicaciones de formularios, los patrones de código que el diseñador del flujo de trabajo lo empuja son malos. Pero puede evitar problemas escribiendo ningún código en el flujo de trabajo y delegando todo el trabajo a otras clases, que pueden organizarse y probarse en unidades de forma más elegante que el flujo de trabajo. Entonces obtienes el aspecto visual genial del diseñador sin la parte oculta del código de spaghetti.

Answer 5

Lo usaría en cualquier entorno en el que necesite trabajar con flujo de trabajo, sin embargo, al usarlo junto con K2 o incluso SharePoint 2007, la potencia de la plataforma es realmente útil. Al desarrollar aplicaciones comerciales con un especialista en BI, se recomienda el uso de la plataforma, que normalmente solo sería relevante para agilizar y mejorar los procesos comerciales.

Para el registro WF fue desarrollado en conjunto con el equipo de desarrollo de K2 y el nuevo K2 Blackpearl está construido sobre WF, al igual que MOSS 2007 y los motores de flujo de trabajo de WSS 3.0.

Answer 6

La compañía actualmente estoy trabajando para establecer un Windows Workflow Foundation (WF) y las razones que se optó por utilizar era porque las reglas con frecuencia sería cambiar y que les obligaría a hacer una recompilación de las diversas DLL, etc. y entonces su solución fue colocar las reglas en el DB y llamarlas desde allí. De esta forma podrían cambiar las reglas y no tener que recompilar y redistribuir las dlls, etc.

Answer 7

Nunca. Probablemente se arrepentirá:

• curva de aprendizaje empinada
• difíciles de depurar
• difícil mantener
• no proporciona suficiente potencia, flexibilidad, o la ganancia de productividad para justificar su uso
• Puede y dañará el estado de la aplicación que no se puede recuperar

El único momento en el que podría concebir el uso de WF es si quisiera alojar el diseñador para un usuario final y probablemente ni siquiera entonces.

Confíe en mí, nada será tan sencillo, poderoso o flexible como el código que usted escribe para hacer exactamente lo que necesita. Mantente alejado de WF.

Por supuesto, esta es solo mi opinión, pero creo que es muy buena. :)

Answer 8

Cuando no desea escribir manualmente todos esos códigos para mantener la interfaz visual, el seguimiento y la persistencia, es una buena elección votar por WF.

Answer 9

En general, si no necesita las funciones de persistencia y seguimiento (que en mi opinión son las características principales), no debe usar Workflow Foundation.

Estas son las ventajas y desventajas de Workflow Foundation recogí de mi experiencia:

Ventajas

• Persistencia: Si usted va a tener muchos procesos de larga ejecución (piense en días, semanas , meses), luego los flujos de trabajo son geniales para esto. Las instancias de flujo de trabajo inactivo se conservan en la base de datos para que no se agote la memoria.
• Seguimiento: WF proporciona el mecanismo para rastrear cada actividad ejecutada en un flujo de trabajo
• * Diseñador Visual: Puse esto como un *, porque creo que esto solo es útil para fines comerciales. Como desarrollador, prefiero escribir código en lugar de unir visualmente las cosas. Y cuando tienes un flujo de trabajo sin desarrollador, a menudo terminas con un gran lío confuso.

Desventajas

• Programación Modelo: Usted está realmente limitado en funciones de programación. Piensa en todas las excelentes características que tienes en C#, luego olvídate de ellas. Los enunciados sencillos de una o dos líneas en C# se convierten en actividades de bloques bastante grandes. Esto es particularmente un dolor para la validación de entrada. Habiendo dicho eso, si realmente tiene cuidado de mantener solo la lógica de alto nivel en los flujos de trabajo, y todo lo demás en C#, entonces podría no ser un problema.
• Rendimiento: los flujos de trabajo consumen una gran cantidad de memoria. Si está implementando muchos flujos de trabajo en un servidor, asegúrese de tener toneladas de memoria. También tenga en cuenta que los flujos de trabajo son mucho más lentos que el código C# normal.
• Curva de aprendizaje cerrada, difícil de depurar: como se mencionó anteriormente. Pasarás mucho tiempo averiguando cómo hacer que las cosas funcionen, y descubriendo la mejor manera de hacer algo.
• Incompatibilidad de la versión del flujo de trabajo: si despliega un flujo de trabajo con persistencia y necesita realizar actualizaciones en el flujo de trabajo, las instancias del flujo de trabajo anterior ya no son compatibles. Supuestamente esto está arreglado en .NET 4.5.
• Tienes que usar expresiones VB (.NET 4.5 permite expresiones C#).
• No flexible: si necesita alguna funcionalidad especial o específica no proporcionada por Workflow Foundation, prepárese para mucho dolor. En algunos casos, tal vez ni siquiera sea posible. ¿Quién sabe hasta que lo intentes? Hay mucho riesgo aquí.
• WCF XAML servicios sin interfaces: normalmente con los servicios WCF, se desarrolla en una interfaz. Con WCF XAML Services, no puede garantizar que WCF XAML Service haya implementado todo en una interfaz. Ni siquiera necesita definir una interfaz. (Por lo que yo sé ...)

Answer 10

de Windows flujos de trabajo seducir a los administradores de TI no codificantes, BAS y similares al igual que su primo BizTalk pero en la práctica la unidad de pruebas, la depuración y la cobertura de código son sólo tres de los muchos trampas. Puedes superar algunos de ellos, pero tienes que invertir mucho para lograr eso, mientras que con código simple lo consigues. Si realmente tienes un requisito de larga duración, entonces probablemente necesites algo más sofisticado. He escuchado la discusión acerca de poder lanzar nuevos archivos xaml a la producción sin volver a compilar dlls, pero sinceramente el tiempo que consumirá Workflows podría ser mejor utilizado para mejorar su integración continua hasta el punto en que los despliegues compilados no sean un problema.

Answer 11

He estado usando el flujo de trabajo de Windows desde hace meses para desarrollar actividades personalizadas y un diseñador alojado de nuevo que los desarrolladores no pueden usar para crear flujos de trabajo. WF es muy potente, pero solo es tan bueno como las actividades personalizadas creadas por los desarrolladores. Cuando se trata de esto, un desarrollador tendría que examinar los flujos de trabajo construidos por no desarrolladores para probar y depurar, pero desde el punto en que pueden crear flujos de trabajo, eso es fantástico.

Además, en los casos en los que tiene procesos de larga ejecución WF es una buena pila tecnológica para usar cuando necesita actualizar procesos dinámicamente, sin tener que reinstalar/descargar o hacer nada, simplemente agregue los nuevos archivos XAML a un directorio y su arquitectura debe configurarse con versiones para eliminar la anterior y usar la nueva.