Boa maneira de programar uma orquestração / processo

5

Estou programando um processo no qual os clientes serão separados em três grupos diferentes e, para cada grupo, uma ação diferente será executada.

Minha pergunta diz respeito ao processo de decidir qual cliente será em qual grupo.

Como entrada, recebi um fluxograma com 7 blocos de decisão.

Eu acho que você pode imaginar o fluxograma:

Se A e B e Não C e F, você está no grupo 1.

Se A e não B e C e E você está no grupo B. Se A e não B e C e não E mas F você também está no grupo B.

De qualquer forma, você provavelmente entende o que quero dizer.

O que estou procurando é o que é uma boa maneira de implementar isso?

Apresentamos as seguintes soluções

1 programa o código como eu digitei:

if A() && !B() && C() || (D() && E()) groupA.Add(client)
if A() && !B() && C() && F()) groupB.Add(client)

2 programe um BIG se / if / else

if A()
    if B()

    else
        if ! C()

        else
else
    if C()

    else

etc.

Mas ... ambos não me fazem feliz, então eu queria saber se havia uma maneira melhor de resolver isso?

    
por Michel 28.05.2015 / 17:07
fonte

1 resposta

3

Definitivamente, existem soluções que tentam modelar fluxogramas de maneira genérica.

Coisas como a base do fluxo de trabalho do Windows, SSIS, roteamento em filas de mensagens, etc.

Mas na minha experiência, a menos que a exigência venha de uma fonte técnica. ou seja, roteamento IP, fail over dns etc onde existe uma especificação técnica para a forma da lógica. É melhor fazer com que o seu código corresponda ao documento de requisitos da mesma forma que descreve a lógica possível

Você terá buracos na lógica e nos resultados que parecem inconsistentes, mas seu código atenderá ao requisito e, quando o requisito mudar de alguma maneira estranha, você não se encontrará em um sistema genérico inteligente que espera que a lógica ser expresso de uma maneira particular.

Isso geralmente se resume a um grande bloco. mas será fácil de ler e fácil de mudar

Atualização: aqui estão as maneiras que fiz / vi no passado e lamentamos

  • Abordagem OOP, persistir objetos lógicos no documento XML, dados em outro, com elementos como < addPercentage condicional="xpath refernce ao documento de dados" value="10" >

o xpath logo ficou super complicado com expressões personalizadas, os usuários nunca se preocuparam em usar a interface, por isso, os desenvolvedores devem receber solicitações para alterar a lógica de qualquer maneira.

  • script eval vb armazenado em db

usuários não podem fazer script vb, trabalhando como uma decisão foi tomada, quase impossível.

  • eval SQL (porque sabemos disso)

os usuários não podem fazer o sql, mesmo probs como com o script vb

  • Orquestração de websphere java com serviços wcf (porque os consultores irão configurar uma 'linguagem de domínio'

os usuários não podem fazer o java / 'language domain' depois que os consultores saem. Contrate uma nova equipe de desenvolvedores java, problemas de implantação / controle de origem com o IDE baseado na web

  • interpretador lisp. OMG Não.

  • fundação do fluxo de trabalho do Windows

desatualizado, mesmo quando o usamos, mais complicado para pequenas tarefas. difícil de explicar aos usuários

  • Pacotes SSIS / DTS porque eles têm uma interface de arrastar e soltar!

Ferramenta hacky para administradores de db que não são de programação, controle de versão, implantação, depuração, dificuldades de desempenho. não escalável.

    
por 28.05.2015 / 17:46
fonte