Application de machine d'état pilotée par les données

Question

Nous travaillons actuellement sur une application de machine d'état "pilotée par les données". À l'heure actuelle, les flux d'état sont tous configurés dans la base de données, mais aucune logique décision/métier n'est configurable dans la base de données avec notre conception actuelle. À cause de cela, le code doit fondamentalement «connaître» le flux d'état, donc il n'y a vraiment aucun intérêt à configurer le flux dans la base de données. J'ai un concept en tête qui nous permettrait de câbler un modèle d'état en utilisant l'injection de dépendances (Spring.NET), mais je ne suis pas sûr de la meilleure façon de rendre cela piloté par les données. Je ne suis pas un grand fan de la configuration d'éléments de type code (comme les noms de classes ou de méthodes) dans la base de données, mais le design que nous avons en tête nécessiterait de câbler l'application dans le DB. fichier), ce qui semble mauvais.

Nous avons étudié Windows WF, mais je pense que nous sommes un peu préoccupés par l'avenir de WF, et si c'est le bon moment pour l'adopter. Je n'ai jamais traité avec les moteurs de règles, donc je me demande si cela pourrait être utile ici. Quelqu'un at-il des suggestions sur la façon de mettre en œuvre cela?

Answer 1

Votre meilleur pari est probablement de découpler les comportements stockés dans les données de la technologie utilisée pour les implémenter.

La manière de procéder est un DSL (langage spécifique au domaine). Venez avec un format qui peut représenter la logique métier dans l'abstrait (c'est-à-dire un micro-langage), en stocker les chaînes dans vos tables et implémenter un interpréteur pour cela dans le code. De cette façon, si la technologie sous-jacente change, il vous suffit de réimplémenter l'interpréteur.

J'ai travaillé sur une application qui utilisait cette technique au milieu des années 1980, et elle a été portée plusieurs fois avec seulement des modifications mineures (et automatisables) des règles métier requises.

Answer 2

Pour le support de langue spécifique au domaine, recherchez here in the MSDN. Vous pouvez également jeter un oeil à Irony mais ce n'est probablement pas encore une solution pour le code productif.