Datengesteuerte State Machine-Anwendung

Question

Wir arbeiten gerade an einer "datengesteuerten" State Machine-Anwendung. Momentan sind alle Statusflüsse in der Datenbank konfiguriert, aber keine der Entscheidungs-/Geschäftslogiken ist in der Datenbank mit unserem aktuellen Design konfigurierbar. Aus diesem Grund muss der Code grundsätzlich auch den Statusfluss "kennen", so dass es wirklich keinen Sinn macht, den Fluss in der Datenbank zu konfigurieren.

Ich habe ein Design im Auge, das es uns ermöglichen würde, ein Zustandsmuster mithilfe von Dependency-Injection (Spring.NET) zu verbinden, aber ich bin mir nicht sicher, wie diese Daten am besten aussehen. Ich bin kein großer Fan von Code-ähnliche Dinge (wie Klassen- oder Methodennamen) in der Datenbank zu konfigurieren, aber das Design, das ich im Auge habe, würde uns erfordern, die Anwendung in der Datenbank zu verdrahten (ähnlich wie in einem Spring XML) Datei), so scheint das schlecht.

Wir haben mit Windows WF untersucht, aber ich denke, wir sind ein wenig besorgt über die Zukunft von WF, und ob dies ein guter Zeitpunkt ist, um es zu übernehmen. Ich habe mich nie mit Regel-Engines beschäftigt, also frage ich mich, ob das hier vielleicht von Nutzen sein könnte. Hat jemand Vorschläge, wie man das umsetzt?

Answer 1

Ihre beste Wette besteht wahrscheinlich darin, die gespeicherten Daten von der Technologie zu entkoppeln, mit der sie implementiert wurden.

Der Weg dazu ist eine DSL (domänenspezifische Sprache). Stellen Sie sich ein Format vor, das die Geschäftslogik abstrakt darstellen kann (d. H. Eine Mikrosprache), speichern Sie die Strings in Ihren Tabellen und implementieren Sie einen Interpreter dafür im Code. Auf diese Weise müssen Sie, wenn sich Ihre zugrunde liegende Technologie ändert, den Interpreter einfach neu implementieren.

Ich arbeitete an einer Anwendung, die diese Technik in der Mitte der 1980er Jahre verwendet, und es wurde mehrmals portiert mit nur geringen (und automatisierbaren) Änderungen an den Geschäftsregeln erforderlich.

Answer 2

Für domänenspezifische Sprachunterstützung siehe here in the MSDN. Sie können auch einen Blick auf Irony werfen, aber dies ist wahrscheinlich noch keine Lösung für produktiven Code.