Una pregunta común que recibo a diario es "cúando debo usar Workflow Foundation, en mi lógica de negocio? en mi cliente? como un almacen de persitencia?". Hace unos días un amigo me escribió un correo comentandome esto:
“Entonces en Workflow Foundation debo reemplazar mi lógica de negocio hecha en código por un workflow secuencial”
Esta pregunta coincide con algo sumamente recurrente que suelo escuchar cada vez que hablo acerca de Workflow Foundation: Dónde encaja Workflow Foundation en mi aplicación
Recuerdo a finales del año 2005 cuando las primeras Beta de la Framework 3.0 o “previews” salieron al aire, recuerdo haberme emocionado muchísimo al leer sobre las “Foundations” (de hecho, en ese tiempo estaba cambiando de plataforma y vivía en un período gris y no podía evitar el comparar cosas en .Net con cosas en lo “otro” en que trabajaba). Una de las cosas que más me llamó la atención fue Workflow Foundation, probablemente porque en uno de nuestros proyectos anteriores pasé un buen tiempo desarrollando una máquina secuencial de flujo y bueno me pareció excelente el que ahora una framework incluyera todo un toolset y “runtime” para el manejo de flujos de trabajo.
Hagamos antes un repaso rápido de qué involucra Workflow Foundation (para conocer un poco más acerca de que hace o se trata, recomiendo este link): http://msdn.microsoft.com/en-us/netframework/aa663328.aspx
- Un runtime para ejecución de procesos (workflows)
- Una serie de bloques o actividades básicas para la construcción de procesos (Activities)
- Un toolset completo para el manejo y diseño de procesos (Addins, Services)
Adicionalmente la framework completa puede extenderse, o sea, embeber el runtime en nuestra aplicación, extender los flujos actuales, crear nuestras propias actividades y servicios y hasta embeber el designer de Workflows en nuestra aplicación.
Bien, entonces nace la pregunta de oro, ¿cuándo usar Workflow Foundation?. Bien, podríamos decir que WF puede usarse en las siguientes situaciones
- Orquestación de pasos o actividades dentro de un modelo de negocio
- Visibilidad del proceso del negocio
- Persistencia en un proceso de negocio
Y bueno, para evitar confusiones, vale la pena mencionar cuándo a mi criterio no debe utilizarse Workflow Foundation
- Para desarrollar la lógica de negocio del sistema
- Para desarrollar una herramienta de programación para personal no técnico
- Para reemplazar un DSL ya establecido en la organización
- Para reemplazar la persistencia de otros aspectos que no están relacionados al proceso en si
Esto es importante, especialmente la primera parte, he visto muchos sistemas que buscan reemplazar o diseñar la lógica de negocio del sistema completamente desde cero usando WF, creo que ese es el ingrediente principal para futuros dolores de cabeza.
En vez de reemplazar o crear la lógica de negocio completamente desde WF, porqué mejor no “orquestamos” esa lógica mediante WF? Un buen indicador de que estamos empleando mal WF es la proliferación de codebehind en el Workflow y de Code Activities. Un buen Workflow debe ser netamente declarativo, eso elimina el uso de Code Activities, de hecho, en Workflow Foundation 4.0 las Code Activities ya no existen.
En resumidas cuentas, Workflow Foundation deben ser un agregado a la lógica de nuestra entidad de negocio y no el core de ella. Debe funcionar como un coordinador entre los pasos o secuencias de cada uno de los servicios o actividades de un proceso actual, debe ser una herramienta de extensión, no una central del desarrollo.
Bueno, como siempre, cuéntenme sus ideas, perspectivas o comentarios al respecto. Soy todo oídos 
