Quando usar o Windows Workflow Foundation? [fechadas]

https://stackoverflow.com/questions/104099

01-07-2019
|

Pergunta

Algumas coisas são mais fáceis de implementar apenas com a mão (código), mas alguns são mais fáceis através de WF. Parece que WF pode ser usado para criar (quase) qualquer tipo de algoritmo. Assim (teoricamente) que posso fazer toda a minha lógica em WF, mas é provavelmente uma má idéia para fazer isso para todos os projetos.

Em que situações é uma boa idéia usar o WF e quando ele vai fazer as coisas mais difíceis, então eles tem que ser? Quais são prós e contras / custo de WF vs. codificação à mão?

Solução

Você pode precisar WF somente se qualquer um dos seguintes forem verdadeiras:

Você tem um processo de longa duração.
Você tem um processo que muda freqüentemente.
Você quer um modelo visual do processo.

Para mais detalhes, veja o post de Paul Andrew: O que usar o Windows workflow Foundation para?

Por favor, não confunda ou se relacionam WF com programação visual de qualquer tipo. É errado e pode levar a arquitetura decisões muito ruins / projeto.

Outras dicas

Nunca. Você provavelmente vai se arrepender:

íngreme curva de aprendizado
Difícil de depuração
Difícil de manter
não fornece energia suficiente, flexibilidade, ou ganho de produtividade para justificar seu uso
pode e irá estado do aplicativo corruptos que não podem ser recuperadas

A única vez que eu jamais poderia conceber usando WF é se eu queria para sediar o designer para um usuário final e, provavelmente, nem mesmo então.

Trust me, nada vai ser tão simples, poderoso, ou flexível, como o código que você escreve para fazer exatamente o que você precisa que ele faça. Fique longe de WF.

Claro, isso é apenas a minha opinião, mas eu acho que é um muito bom. :)

O código gerado pelo WF é desagradável. O valor que WF traz é na representação visual do sistema, embora eu ainda não vi nada (6-7 projectos no trabalho agora com WF que eu estive envolvido com) onde eu não teria preferido um projeto de mão simples codificado .

Em geral, se você não precisa de persistência e recursos de controle (que na minha opinião são as principais características), você não deve usar Workflow Foundation.

Aqui estão as vantagens e desvantagens de Workflow Foundation I recolhidas a partir de minha experiência:

Vantagens

Persistência: Se você está indo ter muitos processos longa execução (pense dias, semanas, meses), então fluxos de trabalho são ótimos para isso. instâncias de fluxo de trabalho ociosas são persistentes no banco de dados para que ele não usar a memória.
Tracking: WF fornece o mecanismo para rastrear cada atividade executada em um fluxo de trabalho
* Visual Designer: Eu coloquei isso como um *, porque eu acho que isso é realmente útil apenas para fins de marketing. Como um desenvolvedor, eu prefiro escrever código, em vez de agarrar as coisas em conjunto visualmente. E quando você tem um não-desenvolvedor fazendo fluxos de trabalho, muitas vezes você acaba com uma enorme confundir confusão.

Desvantagens

Programação Modelo: Você está realmente limitado em recursos de programação. Pense em todas as grandes características que você tem em C #, em seguida, esquecê-los. um simples ou duas declarações de linha em C # se torna um bastante grandes atividades bloco. Isto é particularmente um dor para validação de entrada. Dito isto, se você está realmente cuidado para manter somente a lógica de alto nível em fluxos de trabalho, e tudo o mais em C #, então ele pode não ser um problema.
desempenho: Fluxos de trabalho usar-se uma grande quantidade de memória. Se você estiver implantando uma série de fluxos de trabalho em um servidor, verifique se você tem toneladas de memória. Também estar ciente de que os fluxos de trabalho são muito mais lentos do que o código normal C #.
íngreme curva de aprendizagem, difícil de depurar: Como mencionado acima. Você vai gastar muito tempo tentando descobrir como fazer as coisas de trabalho, e descobrir a melhor maneira de fazer alguma coisa.
Workflow Versão Incompatibilidade: Se você implantar um fluxo de trabalho com persistência, e você precisa fazer atualizações para o fluxo de trabalho, as antigas instâncias de fluxo de trabalho não são mais compatíveis. Supostamente esta é fixa em .NET 4.5.
Você tem que usar expressões VB (.NET 4.5 permite # expressões C).
Não flexível: Se você precisar de algum especial ou funcionalidade específica não fornecido pelo Workflow Foundation, prepare-se para um monte de dor. Em alguns casos, ele pode até não ser possível. Quem sabe até que você tente? Há um monte de risco aqui.
serviços WCF XAML sem interfaces: Normalmente com serviços WCF, você desenvolver contra uma interface. Com WCF XAML Services, você não pode garantir uma XAML Serviço WCF implementou tudo em uma interface. Você não precisa mesmo de definir uma interface. (Tanto quanto eu sei ...)

A principal razão que eu encontrei para usar a fundação fluxo de trabalho é o quanto isso traz-lhe fora da caixa em termos de acompanhamento e persistência. É muito fácil de obter o serviço de persistência instalado e funcionando, o que traz distribuição confiabilidade e carga entre várias instâncias e anfitriões.

Por outro lado, assim como aplicativos formulários, os padrões de código que o fluxo de trabalho de designer empurra-lo em direção são ruins. Mas você pode evitar problemas ao escrever nenhum código no fluxo de trabalho e delegar todo o trabalho para outras classes, que podem ser organizados e unidade testada mais graciosa do que o fluxo de trabalho. Então você começa o aspecto visual legal do designer sem a cruft de trás código espaguete.

Pessoalmente, eu não estou vendido no WF. É de utilidade não era tão óbvio para mim como outras novas tecnologias de MS, como WPF ou WCF.

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

A empresa Atualmente, estou trabalhando para estabelecer um Windows Workflow Foundation (WF) e as razões que escolheu para usá-lo era porque as regras que freqüentemente estar mudando e que iria forçá-los a fazer uma recompilação dos vários de dll, etc, e assim que sua solução era colocar as regras na DB e chamá-los de lá. Dessa forma, eles poderiam mudar as regras e não ter que recompilar e redistribuir o dlls etc

Windows Workflows seduzir não-codificante gerentes de TI, Bas e afins como faz o seu BizTalk primo mas em testes de unidade prática, 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 conseguir que, enquanto com código simples que você acabou de conseguir isso. Se você realmente tem uma exigência de longa duração, em seguida, você provavelmente precisará de algo mais sofisticado. Já ouvi o argumento sobre ser capaz de soltar novos arquivos XAML em produção sem dlls compilação re-mas honestamente o tempo em que fluxos de trabalho vai consumir poderia ser melhor utilizado para melhorar a sua integração contínua para o ponto onde implanta compiladas não são um problema.

Eu iria utilizá-lo em qualquer ambiente onde eu preciso trabalhar com o fluxo de trabalho, no entanto, quando usá-lo em conjunto com K2 ou mesmo SharePoint 2007, o poder da plataforma é verdadeiramente útil. Ao desenvolver aplicativos de negócios com especialista em BI a utilização da plataforma é recomendado e isso normalmente só ser relevante para agilizar e melhorar os processos de negócios.

Para o registro WF foi desenvolvido em conjunto com a equipe de desenvolvimento da K2 eo novo K2 Blackpearl é construído em cima de WF, por isso é MOSS 2007 e mecanismos de workflow WSS 3.0.

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

Eu tenho usado o fluxo de trabalho do Windows por meses agora para desenvolver atividades personalizadas e um designer hospedado-re que os não-desenvolvedores podem usar para criar fluxos de trabalho. WF é muito poderoso, mas é apenas tão bom quanto as atividades personalizados que são criados por desenvolvedores. Quando se trata baixo para ele, um desenvolvedor teria que olhar sobre os fluxos de trabalho construídos por não-desenvolvedores para testar e depurar mas do ponto eles podem criar projecto workflows- que é fantástico.

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

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow