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 encoding manual?
Es posible que necesite WF solo si cualquiera de los siguientes es verdadero:
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:
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
Desventajas
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.