Desde la perspectiva de un no experto, hay dos cosas que me hacen pensar en WF: una única para las plataformas de flujo de trabajo, la otra tal vez más conveniente.
La función de conveniencia es la capacidad de crear nuevas formas de componer actividades. La programación imperativa proporciona solo un repertorio limitado de primitivas de composición: básicamente, secuenciación, if-else y bucles. WF le permite crear sus propios operadores de composición, como ejecución intercalada, ejecución paralela, primero después de la publicación, etc. Y, por supuesto, tiene el sofisticado mecanismo de composición de máquinas de estado integradas.
Digo que esta es una función de conveniencia porque puede construir todos estos operadores en un lenguaje imperativo como C#: de hecho, eso es cómo construye los operadores WF. Pero WF hace que sea fácil usar y leer composiciones personalizadas, mientras que en C# se reduciría rápidamente en una lluvia de expresiones lambda. Entonces, si tiene requisitos complejos de orquestación, es decir, si la forma en que encajan sus actividades es más complicada que las secuencias, si-else y loops, entonces WF puede hacer que su programa sea más fácil de expresar y comprender.
La característica única es durabilidad. Aquí es de donde parte el libro de Shukla y Schmidt, y de dónde sigue volviendo. Un programa imperativo escrito en C# o VB puede ejecutarse durante horas, días, semanas si tiene suerte, tal vez incluso meses ... pero finalmente IIS va a realizar un ciclo del grupo de aplicaciones, o los administradores van a querer instalar las últimas actualizaciones de seguridad , o alguien va a tropezar con el cable de alimentación. ¿Cómo recuerda su programa, "está bien, tengo la orden de compra de Unimaginative Company Names R Us, y estoy esperando una aprobación de crédito de Bank of Breadheads Inc., y cuando lo reciba puedo enviar la confirmación correo electrónico"?
En un programa imperativo convencional, cuando el proceso muere, el estado de ejecución muere con él. Puede comenzar un nuevo proceso, pero comenzará al comienzo del programa. Claro, puede crear una base de datos y usarla para almacenar indicadores como "orden de compra obtenida" y "aprobación de crédito". Pero ahora debe escribir el código específico de la aplicación para guardar y consultar el estado, y volver al punto correcto del programa según ese estado. Y debe diseñar una nueva base de datos y una nueva lógica de guardar/restaurar/saltar para cada aplicación de larga ejecución.
El flujo de trabajo duradero trata de resolver este problema. Si escribe su programa como un flujo de trabajo de actividades, entonces WF se ocupará de persistir en su estado, incluyendo dónde está en su flujo de ejecución. La máquina que ejecuta el programa puede incendiarse y quemar su centro de datos, pero cuando entre la respuesta del banco, WF activará su programa en su otro centro de datos y comenzará a funcionar en el lugar correcto y con la derecha. datos.
Eso para mí es el "caso fuerte" para WF. En muchos casos, no lo necesita: las aplicaciones son lo suficientemente efímeras como para que la falla no sea una preocupación importante, y reiniciar desde cero es una estrategia de recuperación viable. Pero para aplicaciones de larga duración, como dónde puede estar orquestando sistemas externos que pueden tomar horas para responder, o procesos comerciales que involucran a humanos que pueden llevar días responder, la durabilidad puede ser la característica principal de WF.
Descargo de responsabilidad: No soy un programador de WF y nunca he construido un sistema WF del mundo real.Me refiero a esto desde un fondo de BizTalk, y por lo que he leído sobre WF, por lo que esta evaluación es un tanto teórica. Espero que ayude de todos modos!
Capítulo 1 de Shukla y de Schmidt "Essential Workflow Foundation "motiva tanto los casos de uso como el diseño de WF desde cero en 31 páginas cortas. Es una de las mejores explicaciones de "ahora lo entiendo" de una tecnología que he visto desde "Essential COM", y no puedo recomendarlo lo suficiente. * Sin embargo *, el libro trata mucho sobre los fundamentos, por lo que * no * responde a sus requisitos para "enseñar WF" o ejecutar ejemplos de casos de estudio de casos. Todavía es muy valioso para entrar en la mentalidad, y como alguien que tenía el mismo "¿estoy recibiendo esto?" ¡Sintiéndolo definitivamente me ayudó! – itowlson
Muy buena pregunta, siempre estoy luchando con mis colegas cuando trato de decidir si voy por el camino de WF o no. Un principio que siempre he aplicado con una buena tasa de éxito es que si no está seguro si necesita una WF o no, entonces es muy probable que no necesite la WF. –