Aplicativo de máquina de estado orientado a dados

Question

No momento, estamos trabalhando em um aplicativo de máquina de estado "orientado a dados". No momento, os fluxos de estado estão todos configurados no banco de dados, mas nenhuma das lógicas de decisão/negócios é configurável no banco de dados com nosso design atual. Por esse motivo, o código também deve "saber" o fluxo de estado, portanto, não há realmente sentido em configurar o fluxo no banco de dados.

Tenho um design em mente que nos permitiria conectar um padrão de estado usando injeção de dependência (spring.net), mas não tenho certeza da melhor maneira de fazer isso orientado a dados. Não sou um grande fã de configurar coisas semelhantes a código (como nomes de classe ou métodos) no banco de dados, mas o design que tenho em mente exigiria que conectassemos o aplicativo no banco de dados (semelhante à fiação em um xml de primavera arquivo), então isso parece ruim.

Investigamos o uso do Windows WF, mas acho que estamos um pouco preocupados com o futuro do WF e se este é um bom momento para adotá -lo. Eu nunca lidei com os motores de regras, por isso estou me perguntando se isso pode ser de alguma utilidade aqui. Alguém tem alguma sugestão sobre como implementar isso?

Answer 1

Sua melhor aposta é provavelmente dissociar os comportamentos armazenados em dados da tecnologia usada para implementá-los.

A maneira de fazer isso é um DSL (idioma específico do domínio). Crie um formato que possa representar a lógica de negócios em resumo (ou seja, um micro linguagem), armazenar strings disso em suas tabelas e implementar um intérprete para ele no código. Dessa forma, se a sua tecnologia subjacente mudar, basta reimplementar o intérprete.

Eu trabalhei em um aplicativo que usou essa técnica em meados dos anos 80 e foi portada várias vezes com apenas alterações menores (e automatíveis) nas regras de negócios necessárias.

Answer 2

Para o domínio de suporte específico de linguagem, look Aqui no MSDN. Você também pode dar uma olhada Ironia Mas isso provavelmente ainda não é uma solução para código produtivo.