¿Cuándo usar Windows Workflow Foundation?

Es posible que necesite WF solo si cualquiera de los siguientes es verdadero:

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é sirve Windows Workflow Foundation?

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

Nunca. Probablemente lo lamentes:

• 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 pude concebir el uso de WF es si quería alojar al diseñador para un usuario final y probablemente ni siquiera entonces.

Créame, 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. 🙂

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 .

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 que reuní 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 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

• Modelo de progtwigción: tiene limitaciones en las funciones de progtwigció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 pronunciada, 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 implementa 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 es flexible: si necesita alguna funcionalidad especial o específica no provista 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í.
• Servicios WCF XAML sin interfaces: normalmente con los servicios de WCF, se desarrollan contra 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 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 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.

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.

La empresa en la que estoy trabajando actualmente creó una Windows Workflow Foundation (WF) y las razones por las que eligieron usarla se debían a que las reglas cambiarían con frecuencia y eso los forzaría a hacer una recomstackción de los diversos archivos DLL, etc. fue colocar las reglas en el DB y llamarlas desde allí. De esta forma podrían cambiar las reglas y no tener que recomstackr y redistribuir las dlls, etc.

Los flujos de trabajo de Windows seducen a los administradores de TI no codificados, BAs y similares, al igual que su primo BizTalk, pero en la práctica las pruebas unitarias, la depuración y la cobertura de códigos son solo tres de los muchos escollos. 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 comstackr 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 comstackdos no sean un problema.

Lo usaría en cualquier entorno en el que necesite trabajar con flujo de trabajo, sin embargo, al usarlo en conjunción 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.

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

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 que no son desarrolladores 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 stack de tecnología 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 architecture debe ser configurar con versiones para eliminar el anterior y usar el nuevo.