Quando usar a Fundação Windows Workflow? [fechado]

• curva de aprendizagem íngreme
• difícil de depurar
• difícil de manter
• não fornece energia suficiente, flexibilidade ou ganho de produtividade para justificar a sua utilização
• pode e irá corromper o estado de aplicação que não pode ser recuperado

A única vez que eu poderia conceber de usar WF é se eu quisesse apresentar o designer para um usuário final e provavelmente nem mesmo nessa altura.

Em geral, se você não precisa das características de persistência e rastreamento (que na minha opinião são as principais características), Você não deve usar a Fundação Workflow.

Vantagens

Persistência: se você vai ter muitos processos de longa duração (dias, semanas, meses), então os fluxos de trabalho são ótimos para isso. As instâncias de fluxo de trabalho inactivo persistem no base de dados para não usar a memória.
• seguimento: o WF fornece o mecanismo para seguir cada actividade executada num fluxo de trabalho
• *Designer Visual: ponho isto como um*, porque acho que isto só é útil para fins de marketing. Como desenvolvedor, prefiro escrever código em vez de encaixar as coisas visualmente. E quando você tem um não-Desenvolvedor fazendo fluxos de trabalho, você muitas vezes acaba com uma enorme confusão bagunca.

Desvantagens

Modelo de programação: você é muito limitado em recursos de programação. Pense em todas as grandes características que você tem em C#, em seguida, esqueça sobre eles. Simple one or two line statements in C# becomes a fairly large block activities. Isto é particularmente difícil de validar. Tendo dito isso, se você é realmente cuidadoso para manter apenas a lógica de alto nível em fluxos de trabalho, e tudo o resto em C#, então pode não ser um problema.
• Desempenho: os fluxos de trabalho consomem uma grande quantidade de memória. Se você está implantando muitos fluxos de trabalho em um servidor, certifique-se de que você tem toneladas de memória. Também esteja ciente de que os fluxos de trabalho são muito mais lentos do que o código C# normal.
• curva de aprendizagem íngreme, difícil de depurar: como mencionado acima. Vais passar muito tempo a descobrir como fazer as coisas funcionarem, e a descobrir a melhor maneira de fazer alguma coisa.
• incompatibilidade da versão do fluxo de trabalho: se implantar um fluxo de trabalho com persistência, e você precisa fazer atualizações para o fluxo de trabalho, as instâncias antigas do fluxo de trabalho não são mais compatíveis. Supostamente, isto está fixado em. Net 4.5.
• tem de usar expressões VB (o.net 4. 5 permite expressões C#).
• Não flexível: se precisar de alguma funcionalidade especial ou específica não fornecida pela Workflow Foundation, prepare-se para muita dor. Em alguns casos, pode nem ser possível. Quem sabe até tentares? Há muito risco aqui.
• WCF XAML serviços sem interfaces: normalmente com serviços WCF, você se desenvolve contra uma interface. Com os Serviços WCF XAML, você não pode garantir que um serviço WCF XAML tenha implementado tudo em uma interface. Você nem precisa definir uma interface. (tanto quanto sei...)

A empresa que eu estou trabalhando atualmente para configurar um Windows Workflow Foundation (WF) e as razões que escolhi para usar foi porque as regras seria freqüentemente mudando e que forçá-los a fazer uma recompilação das várias dll's, etc, e então a sua solução foi colocar as regras no banco de dados e chamá-los de lá. Desta forma, poderiam alterar as regras e não ter de recompilar e redistribuir os dlls, etc.

Os fluxos de trabalho do Windows seduzem os gestores de TI que não codificam, o BAs e outros como o seu primo BizTalk, mas na prática os testes unitários, depuração e cobertura de código são apenas três das muitas armadilhas. Você pode superar alguns deles, mas você tem que investir pesadamente em alcançar isso, enquanto que com um código simples você só consegue isso. Se você realmente tem uma exigência de longa duração, então você provavelmente precisa de algo mais sofisticado. Eu ouvi a discussão sobre ser capaz de lançar novos arquivos xaml em produção sem re-compilar dlls, mas honestamente o tempo que os fluxos de trabalho vão consumir poderia ser melhor usado para melhorar a sua integração contínua ao ponto em que as implementações compiladas não são um problema.

Tenho usado o workflow do Windows há meses para desenvolver actividades personalizadas e um designer que não-programadores podem usar para construir fluxos de trabalho. WF é muito poderoso, mas é tão bom quanto as atividades customizadas que são construídas pelos desenvolvedores. Quando se trata disso, um desenvolvedor teria que olhar sobre fluxos de trabalho construídos por não-desenvolvedores para testar e depurar, mas a partir do ponto em que eles podem criar fluxos de trabalho rascunho - isso é fantástico.

Além disso, nos casos em que processos longos WF é uma boa pilha de tecnologia para usar quando você precisa atualizar processos dinamicamente-sem ter que reinstalar/baixar ou fazer qualquer coisa, basta adicionar os novos arquivos XAML a um diretório e sua arquitetura deve ser configurada com versionamento para raspar o antigo e usar o novo.