Quando usar o Windows Workflow Foundation? [fechadas]

Algumas coisas são mais fáceis de implementar apenas à mão (código), mas outras são mais fáceis através do WF. Parece que o WF pode ser usado para criar (quase) qualquer tipo de algoritmo. Então (teoricamente) eu posso fazer toda a minha lógica no WF, mas provavelmente é uma má idéia fazê-lo para todos os projetos.

Em que situações é uma boa ideia usar o WF e quando isso dificultará as coisas? Quais são os prós e os contras / custo do WF vs. codificação manualmente?

Você pode precisar do WF apenas se alguma das seguintes situações for verdadeira:

1. Você tem um processo de execução demorada.
2. Você tem um processo que muda frequentemente.
3. Você quer um modelo visual do processo.

Para obter mais detalhes, consulte a publicação de Paul Andrew: Para que usar o Windows Workflow Foundation?

Por favor, não confunda ou relacione o WF com programação visual de qualquer tipo. Está errado e pode levar a decisões muito ruins de arquitetura / design.

Nunca. Você provavelmente vai se arrepender:

• Curva de aprendizado acentuada
• Difícil de depurar
• Difícil de manter
• Não fornece energia, flexibilidade ou ganho de produtividade suficiente para justificar seu uso
• Pode e irá corromper o estado do aplicativo que não pode ser recuperado

A única vez que eu poderia conceber usar o WF é se eu quisesse hospedar o designer para um usuário final e provavelmente nem mesmo nesse momento.

Confie em mim, nada será tão direto, poderoso ou flexível quanto o código que você escreve para fazer exatamente o que você precisa. Fique longe do WF.

Claro, essa é apenas a minha opinião, mas acho que é muito boa. :)

O código gerado pelo WF é desagradável. O valor que o WF agrega está na representação visual do sistema, embora eu ainda não tenha visto nada (6-7 projetos em andamento agora com o WF com o qual eu estive envolvido) em que eu não teria preferido um projeto codificado à mão mais simples .

Em geral, se você não precisa dos recursos de persistência e rastreamento (que na minha opinião são os principais), não deve usar o Workflow Foundation.

Aqui estão as vantagens e desvantagens do Workflow Foundation que reuni com a minha experiência:

Vantagens

• Persistência: se você tiver muitos processos de execução longa (dias, semanas, meses), os fluxos de trabalho são ótimos para isso. As instâncias ociosas do fluxo de trabalho são mantidas no banco de dados para que não consuma memória.
• Rastreamento: o WF fornece o mecanismo para rastrear cada atividade executada em um fluxo de trabalho
• * Visual Designer: coloquei isso como *, porque acho que isso é realmente útil apenas para fins de marketing. Como desenvolvedor, prefiro escrever código em vez de juntar as coisas visualmente. E quando você tem um fluxo de trabalho de um desenvolvedor que não é desenvolvedor, geralmente acaba com uma enorme confusão.

Desvantagens

• Modelo de programação: você é realmente limitado em recursos de programação. Pense em todos os ótimos recursos que você tem em C # e depois os esqueça. Instruções simples de uma ou duas linhas em C # tornam-se atividades de bloco bastante grandes. Isso é particularmente difícil para a validação de entrada. Dito isto, se você for realmente cuidadoso em manter apenas a lógica de alto nível nos fluxos de trabalho e tudo o mais em C #, talvez não seja um problema.
• Desempenho: os fluxos de trabalho usam uma grande quantidade de memória. Se você estiver implantando muitos fluxos de trabalho em um servidor, verifique se possui muita memória. Lembre-se também de que os fluxos de trabalho são muito mais lentos que o código C # normal.
• Curva de aprendizado íngreme, difícil de depurar: Como mencionado acima. Você vai gastar muito tempo descobrindo como fazer as coisas funcionarem e descobrindo a melhor maneira de fazer alguma coisa.
• Incompatibilidade da versão do fluxo de trabalho: se você implantar um fluxo de trabalho com persistência e precisar fazer atualizações no fluxo de trabalho, as instâncias antigas do fluxo de trabalho não serão mais compatíveis. Supostamente, isso foi corrigido no .NET 4.5.
• Você precisa usar expressões VB (o .NET 4.5 permite expressões C #).
• Não flexível: se você precisar de alguma funcionalidade especial ou específica não fornecida pela Workflow Foundation, prepare-se para muita dor. Em alguns casos, pode até não ser possível. Quem sabe até você tentar? Há muito risco aqui.
• Serviços WCF XAML sem interfaces: normalmente com serviços WCF, você desenvolve uma interface. Com os Serviços XAML do WCF, você não pode garantir que um Serviço XAML do WCF tenha implementado tudo em uma interface. Você nem precisa definir uma interface. (até onde sei...)

O principal motivo que encontrei para usar a base do fluxo de trabalho é o quanto ela traz para você imediatamente em termos de rastreamento e persistência. É muito fácil colocar o serviço de persistência em funcionamento, o que traz confiabilidade e distribuição de carga entre várias instâncias e hosts.

Por outro lado, assim como os aplicativos de formulários, os padrões de código pelos quais o designer de fluxo de trabalho o leva são ruins. Mas você pode evitar problemas escrevendo nenhum código no fluxo de trabalho e delegando todo o trabalho para outras classes, que podem ser organizadas e testadas com mais facilidade do que o fluxo de trabalho. Então você obtém o aspecto visual legal do designer sem o fragmento de código de espaguete por trás.

Pessoalmente, não sou vendido no WF. Sua utilidade não era tão óbvia para mim quanto outras novas tecnologias de MS, como WPF ou WCF.

Eu acho que o WF será muito usado em aplicativos de negócios no futuro, mas não tenho planos de usá-lo, porque não parece a ferramenta certa para o trabalho em meus projetos.

Atualmente, a empresa em que estou trabalhando para configurar um Windows Workflow Foundation (WF) e os motivos pelos quais eles escolheram usá-lo foram porque as regras frequentemente mudavam e isso os forçava a recompilar as várias dlls etc. e, portanto, sua solução era colocar as regras no banco de dados e chamá-las de lá. Dessa forma, eles podem alterar as regras e não precisam recompilar e redistribuir as DLLs etc.

Os fluxos de trabalho do Windows seduzem gerentes de TI não codificantes, BAs e similares, assim como seu primo BizTalk, mas na prática testes de unidade, depuração e cobertura de código são apenas três das muitas armadilhas. Você pode superar alguns deles, mas precisa investir muito para conseguir isso, enquanto que com o código simples você obtém isso. Se você realmente tem um requisito de longa duração, provavelmente precisará de algo mais sofisticado. Ouvi o argumento de poder soltar novos arquivos xaml em produção sem recompilar dlls, mas honestamente o tempo que os fluxos de trabalho consumirão poderia ser melhor usado para melhorar sua integração contínua até o ponto em que implantações compiladas não são um problema.

Eu o usaria em qualquer ambiente em que precise trabalhar com o fluxo de trabalho; no entanto, ao usá-lo em conjunto com o K2 ou mesmo o SharePoint 2007, o poder da plataforma é realmente útil. Ao desenvolver aplicativos de negócios com o especialista em BI, recomenda-se o uso da plataforma, o que normalmente seria relevante apenas para otimizar e aprimorar os processos de negócios.

Para o registro, o WF foi desenvolvido em conjunto com a equipe de desenvolvimento da K2 e o novo K2 Blackpearl é construído sobre o WF, assim como os mecanismos de fluxo de trabalho do MOSS 2007 e WSS 3.0.

Quando você não deseja escrever manualmente todos esses códigos para manter a interface visual, o rastreamento e a persistência, é uma escolha sábia votar no WF.

Estou usando o fluxo de trabalho do Windows há meses para desenvolver atividades personalizadas e um designer hospedado novamente que não desenvolvedores podem usar para criar fluxos de trabalho. O WF é muito poderoso, mas é tão bom quanto as atividades personalizadas criadas pelos desenvolvedores. Quando se trata disso, um desenvolvedor precisa examinar os fluxos de trabalho criados por não-desenvolvedores para testar e depurar, mas a partir do ponto em que eles podem criar fluxos de trabalho de rascunho, isso é fantástico.

Além disso, nos casos em que você possui processos de execução longa, o WF é uma boa pilha de tecnologia para usar quando você precisa atualizar processos dinamicamente - sem precisar reinstalar / fazer o download ou fazer qualquer coisa, basta adicionar os novos arquivos XAML a um diretório e sua arquitetura deve ser configurado com versionamento para descartar o antigo e usar o novo.