.net - sirve - ¿Cuándo usar Windows Workflow Foundation?

windows workflow foundation para que sirve (11)

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.

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?

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 programación: tiene limitaciones en las 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 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é...)

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

Tienes un proceso de larga duración.
Tienes un proceso que cambia con frecuencia.
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 programación visual de ningún tipo. Está mal y puede llevar a decisiones de arquitectura / diseño muy malas.

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 pila 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 arquitectura debe ser configurar con versiones para eliminar el anterior y usar el nuevo.

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 recompilació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 recompilar y redistribuir las dlls, etc.

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.

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.

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 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.

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. :)

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.

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 .