¿Cuándo usar Windows Workflow Foundation? [cerrado]

Algunas cosas son más fáciles de implementar solo a mano (código), pero otras son más fáciles a través de WF. Parece que WF se puede usar para crear (casi) cualquier tipo de algoritmo. Entonces (en teoría) 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 hará las cosas más difíciles de lo que tienen que ser? ¿Cuáles son los pros y los contras / el costo de WF versus la codificación a mano?

Es posible que necesite WF solo si se cumple alguna de las siguientes condiciones:

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

Para obtener más detalles, consulte la publicación de Paul Andrew: ¿Para qué usar Windows Workflow Foundation?

No confunda ni relacione WF con la programación visual de ningún tipo. Está mal y puede llevar a decisiones muy malas de arquitectura / diseño.

Nunca. Probablemente lo lamentarás:

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

La única vez que podría concebir el uso de WF es si quisiera alojar al diseñador para un usuario final y probablemente ni siquiera entonces.

Confía en mí, nada será tan directo, poderoso o flexible como el código que escribes para hacer exactamente lo que necesitas que haga. Manténgase alejado de WF.

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

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

En general, si no necesita las características 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 que obtuve de mi experiencia:

Ventajas

• Persistencia: si va a tener muchos procesos de larga ejecución (piense en días, semanas, meses), los flujos de trabajo son excelentes para esto. Las instancias de flujo de trabajo inactivo se mantienen en la base de datos para que no use memoria.
• Seguimiento: WF proporciona el mecanismo para rastrear cada actividad ejecutada en un flujo de trabajo
• * Diseñador visual: pongo esto como *, porque creo que esto realmente solo es útil para fines de marketing. Como desarrollador, prefiero escribir código en lugar de juntar cosas visualmente. Y cuando tiene un flujo de trabajo que no es desarrollador, a menudo termina con un gran desastre confuso.

Desventajas

• Modelo de programación: Realmente tienes limitaciones en las funciones de programación. Piensa en todas las excelentes funciones que tienes en C #, luego olvídate de ellas. Las declaraciones simples de una o dos líneas en C # se convierten en actividades de bloque bastante grandes. Esto es particularmente un dolor para la validación de entrada. Dicho esto, si tiene mucho 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 utilizan 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 empinada, difícil de depurar: como se mencionó anteriormente. Pasarás mucho tiempo descubriendo 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 implementa un flujo de trabajo con persistencia y necesita realizar actualizaciones en el flujo de trabajo, las instancias anteriores del flujo de trabajo ya no son compatibles. Supuestamente esto se arregla en .NET 4.5.
• Debe 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, puede que ni siquiera sea posible. ¿Quién sabe hasta que lo intentes? Hay mucho riesgo aquí.
• Servicios XAML de WCF sin interfaces: normalmente, con servicios de WCF, se desarrolla en una interfaz. Con los servicios WCF XAML, no puede garantizar que un servicio WCF XAML haya implementado todo en una interfaz. Ni siquiera necesita definir una interfaz. (por lo que sé...)

La razón principal que he encontrado para usar 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 funcionamiento el servicio de persistencia, lo que brinda confiabilidad y distribución de carga entre múltiples instancias y hosts.

Por otro lado, al igual que las aplicaciones de formularios, los patrones de código hacia los que el diseñador de 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 se pueden organizar y probar en la unidad con más gracia que el flujo de trabajo. Luego obtienes el aspecto visual genial del diseñador sin el resto del código de espagueti detrás.

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 utilizará en gran medida 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.

La compañía para la que estoy trabajando actualmente configuró una Windows Workflow Foundation (WF) y las razones por las que eligieron usarla se debieron a que las reglas cambiarían con frecuencia y eso los obligaría a hacer una recopilación de los diversos dll, etc., por lo que su solución era colocar las reglas en el DB y llamarlas desde allí. De esta manera, podrían cambiar las reglas y no tener que volver a compilar y redistribuir los dlls, etc.

Los flujos de trabajo de Windows seducen a los gerentes de TI sin codificación, BA y similares, al igual que su primo BizTalk, pero en la práctica las pruebas unitarias, la depuración y la cobertura del código son solo tres de los muchos escollos. Puede superar algunos de ellos, pero tiene que invertir mucho para lograrlo, mientras que con el código simple solo obtiene eso. Si realmente tiene un requisito de larga duración, probablemente necesite algo más sofisticado. He escuchado el argumento sobre la posibilidad de colocar nuevos archivos xaml en producción sin volver a compilar dlls, pero sinceramente, el tiempo que consumirán los flujos de trabajo podría utilizarse mejor para mejorar su integración continua hasta el punto en que las implementaciones compiladas no sean un problema.

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

Para el registro, WF se desarrolló junto con el equipo de desarrollo de K2 y el nuevo K2 Blackpearl está construido sobre WF, al igual que los motores de flujo de trabajo MOSS 2007 y WSS 3.0.

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

He estado usando el flujo de trabajo de Windows durante meses para desarrollar actividades personalizadas y un diseñador alojado de nuevo que los no desarrolladores pueden usar para crear flujos de trabajo. WF es muy poderoso, pero es tan bueno como las actividades personalizadas que desarrollan los desarrolladores. Cuando se trata de eso, un desarrollador tendría que revisar los flujos de trabajo creados por personas que no son desarrolladores para probar y depurar, pero desde el punto en que pueden crear flujos de trabajo de borrador, eso es fantástico.

Además, en los casos en 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 debería ser configurar con versiones para descartar el antiguo y utilizar el nuevo.