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

Question

Algunas cosas son más fáciles de implementar simplemente a mano (código), pero otras son más fáciles a través de WF.Parece que WF se puede utilizar 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 utilizar WF y cuándo hará las cosas más difíciles de lo que deberían ser?¿Cuáles son las ventajas y desventajas/costo de WF vs.codificar a mano?

Answer 1

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. Quieres un modelo visual del proceso.

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

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

Answer 2

Nunca.Probablemente te arrepientas:

• Curva de aprendizaje pronunciada
• Difícil de depurar
• Difícil de mantener
• No proporciona suficiente potencia, flexibilidad o aumento de productividad para justificar su uso.
• Puede dañar 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 el diseñador para un usuario final y probablemente ni siquiera entonces.

Créame, nada será tan sencillo, potente o flexible como el código que escriba para hacer exactamente lo que necesita.Manténgase alejado de WF.

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

Answer 3

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 en los que he estado involucrado) en los que no hubiera preferido un proyecto codificado a mano más simple. .

Answer 4

En general, si no necesita las funciones de persistencia y seguimiento (que en mi opinión son las funciones principales), no debería utilizar 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 inactivas se conservan en la base de datos para que no consuman 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 en realidad sólo es útil con fines de marketing.Como desarrollador, prefiero escribir código en lugar de unir cosas visualmente.Y cuando tienes a una persona que no es un desarrollador realizando flujos de trabajo, a menudo terminas con un enorme lío confuso.

Desventajas

• Modelo de programación:Estás realmente limitado en funciones de programación.Piense en todas las excelentes funciones que tiene en C# y luego olvídese de ellas.Las declaraciones simples de una o dos líneas en C# se convierten en un bloque de actividades bastante grande.Esto es particularmente complicado para la validación de entradas.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 puede que no sea un problema.
• Actuación:Los flujos de trabajo consumen una gran cantidad de memoria.Si está implementando muchos flujos de trabajo en un servidor, asegúrese de tener mucha 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 pronunciada, difícil de depurar:Como se ha mencionado más arriba.Pasará mucho tiempo descubriendo cómo hacer que las cosas funcionen y descubriendo la mejor manera de hacer algo.
• Incompatibilidad de versión de flujo de trabajo:Si implementa un flujo de trabajo con persistencia y necesita realizar actualizaciones en el flujo de trabajo, las instancias de flujo de trabajo antiguas ya no serán compatibles.Supuestamente esto está solucionado 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 que Workflow Foundation no proporciona, prepárese para sufrir mucho dolor.En algunos casos, puede que ni siquiera sea posible.¿Quién sabe hasta que lo intentas?Hay mucho riesgo aquí.
• Servicios WCF XAML sin interfaces:Normalmente, con los servicios WCF, se desarrolla contra una interfaz.Con los servicios WCF XAML, no puede garantizar que un servicio WCF XAML haya implementado todo en una interfaz.Ni siquiera necesitas definir una interfaz.(Por lo que yo sé...)

Answer 5

La razón principal que he encontrado para usar la base de flujo de trabajo es lo innovador que es en términos de seguimiento y persistencia.Es muy fácil poner en funcionamiento el servicio de persistencia, lo que aporta 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 a los que te empuja el diseñador de flujo de trabajo son malos.Pero puede evitar problemas si no escribe código en el flujo de trabajo y delega todo el trabajo a otras clases, que pueden organizarse y probarse unitariamente de manera más elegante que el flujo de trabajo.Luego obtienes el atractivo aspecto visual del diseñador sin el montón de código espagueti detrás.

Answer 6

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

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

Answer 7

La empresa para la que trabajo actualmente configuró Windows Workflow Foundation (WF) y las razones por las que eligieron usarlo fue porque las reglas cambiaban con frecuencia y eso los obligaría a volver a compilar los distintos dll, etc., y así su solución. Era colocar las reglas en la base de datos y llamarlas desde allí.De esta manera podrían cambiar las reglas y no tener que recompilar y redistribuir los archivos DLL, etc.

Answer 8

Los flujos de trabajo de Windows seducen a los administradores de TI, BA y similares que no saben codificar, al igual que su primo BizTalk, pero en la práctica las pruebas unitarias, la depuración y la cobertura del código son sólo tres de los muchos obstáculos.Puedes superar algunos de ellos, pero tienes que invertir mucho para lograrlo, mientras que con el código simple simplemente lo consigues.Si realmente tiene un requisito de larga duración, probablemente necesite algo más sofisticado.Escuché el argumento sobre poder colocar nuevos archivos xaml en producción sin volver a compilar los archivos DLL, pero honestamente, el tiempo que consumirán los flujos de trabajo podría usarse mejor para mejorar su integración continua hasta el punto en que las implementaciones compiladas no sean un problema.

Answer 9

Lo usaría en cualquier entorno donde 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 agilizar y mejorar los procesos comerciales.

Para que conste, WF se desarrolló en conjunto 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.

Answer 10

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.

Answer 11

He estado usando el flujo de trabajo de Windows durante meses para desarrollar actividades personalizadas y un diseñador realojado que los no desarrolladores pueden usar para crear flujos de trabajo.WF es muy poderoso, pero es tan bueno como las actividades personalizadas creadas por los desarrolladores.A fin de cuentas, un desarrollador tendría que revisar los flujos de trabajo creados por no desarrolladores para probarlos y depurarlos, pero desde el punto de vista de que pueden crear borradores de flujos de trabajo, eso es fantástico.

Además, en los casos en los que tiene procesos de ejecución prolongada, WF es una buena pila tecnológica para usar cuando necesita actualizar procesos dinámicamente, sin tener que reinstalar/descargar ni hacer nada, simplemente agregue los nuevos archivos XAML a un directorio y su arquitectura debería ser configurar con control de versiones para desechar el anterior y usar el nuevo.