c# - library - stateless github

Comparación entre Stateless(en código google) y Windows Workflow (1)

Estoy empezando a pensar que debería abandonar Windows WF a favor de algo más simple. No necesariamente necesito detener la ejecución del flujo de trabajo por períodos prolongados y restaurarlos más tarde. Sin embargo, me gustaría un marco de máquina de estado simple que tenga suspensión / reanudación / cancelación básica (sin serialización).

He descargado el marco sin estado de Google Code y voy a empezar a jugar con él, pero me encantaría escuchar lo que están usando los otros programadores de .NET.

EDITAR Apátridas parece muy fácil de implementar, pero me pregunto si es lo correcto para una máquina de caramelos. En la automatización, siempre me siento en conflicto sobre cómo deben usarse las máquinas de estado. Aunque utilizo el término "máquina de estado", lo hago de manera poco estricta porque lo uso más como un diagrama de flujo. En lugar de usar estados para representar el modo actual en el que se encuentra una máquina, lo uso para ejecutar funciones. Entonces, en este caso con Stateless, estaría usando la transición de un estado al siguiente como el mecanismo para llamar funciones en el controlador de mi máquina de dulces. ¿Pensamientos?

Mientras trabajo en esto, intentaré enumerar algunas de las cosas que estoy buscando. La mayoría probablemente será un poco superficial desde el punto de vista del análisis (especialmente porque soy nuevo en ambos frameworks), pero espero que ayude a alguien.

Apátrida

Pros

fuente abierta
sintácticamente conciso y fácil de leer
buenos ejemplos en el repo mercurial en el código de google
Puedo traducir mi diagrama de estado UML en código usando sin estado muy rápidamente.
el mantenimiento del estado es muy simple: puedo agregar y eliminar con facilidad. Los métodos de extensión me permiten configurar los estados en líneas separadas, por lo que puedo comentar los desencadenantes o acciones que no quiero usar.
pasar datos a / desde la máquina de estado es fácil y puede hacerlo como lo desee en código subyacente.
Del mismo modo, la máquina de estado puede actualizar la GUI en una variedad de formas. En este momento, estoy modificando datos a través de una interfaz, y luego la GUI usa un temporizador para actualizar sus elementos. Probablemente también podría usar un BackgroundWorker para hacer esto.
Empecé a usar subestados para manejar mi GUI, que necesita administrar varios estados como En ejecución, Detenido, Abortado e Inactivo. El estado Detenido tiene subestados porque el usuario puede pausar el sistema de varias formas, pero los desencadenantes de reanudación son específicos de la forma en que se pausaron. Me encanta poder administrar la activación / desactivación y la información sobre herramientas de mi GUI mediante el uso de un marco de máquina de estado liviano.

Contras

no hay mecanismos incorporados para pausa, reanudar, abortar
solo un desarrollador que apoya el proyecto. Obtuve asistencia con un problema que encontré recientemente, sin embargo.
potencial de mal uso si no tienes cuidado. Implementé el marco de máquina de estado incorrectamente en mi primer intento. Funcionó muy bien durante meses, y finalmente murió cuando ejecuté un proceso muy largo. Resultó que causaba que los manejadores de estado se acumularan y tuve una condición de desbordamiento de pila.

Windows Workflow Foundation

Pros

enfoque gráfico para diseñar el flujo de trabajo
persistencia de soporte, pausar, reanudar, abortar flujos de trabajo
MS probablemente tiene un gran equipo de programadores para apoyar esto
GUI hace que sea muy fácil deshabilitar / volver a habilitar actividades

Contras

enfoque gráfico para diseñar el flujo de trabajo oculta el hecho de que esto es bastante complejo
Para poder utilizar la persistencia y obtener pausa / reanudar / abortar, debe instalar y configurar un "servicio de persistencia", algo que todavía no he descubierto para trabajar. Puedo configurar bien la base de datos SQL, pero en el tiempo de ejecución recibo un montón de errores que no entiendo.
porque es de MS, no sabes si durará mucho o se abandonará por completo.
el manejo de errores es un poco extraño porque puede usar código detrás o un FaultHandler
Pasar datos de WF a su aplicación principal es complicado y requiere algo como WCF (otra tecnología que no tengo suficiente tiempo para aprender adecuadamente en este momento), o usar la interfaz ExternalDataExchange.