Tool (Control) für Rule Engine GUI

Question

Nach der Bewertung von Standardprodukten (MSBRE, Drools etc) schreiben wir unsere eigene Regel-Engine (diese Entscheidung wurde getroffen, bitte nicht andere Regeln Motoren - aber Teile von denen, die die Details tun, die ich will, sind sehr willkommen).

Was ich möchte ist, den Benutzern eine einfache GUI zu geben, die es ihnen erlauben würde, eines unserer Domain "Objekte" zu nehmen und eine Regel in der GUI zu erstellen, die in Xml oder (idealerweise) .net Code übersetzt werden kann .

So könnte der Benutzer zum Beispiel eine StaffDuty wählen und sagen "Wenn der Mitarbeiter in der Management Group ist und der heutige Dienst länger als 8 Stunden ist, stellen Sie sicher, dass das Zeichen für morgen nach 08:00 Uhr ist". Das StaffDuty-Objekt verfügt über Gruppen-, DutyTime- und NextDuty-Eigenschaften, und NextDuty ist ein Typ mit einer SignOn-Eigenschaft.

Ich möchte in der Lage sein, das etwas grafisch mit dem Benutzer anzuzeigen, "die Bits ausfüllend" und es dann speichernd, damit wir das dann in Code umwandeln können (vielleicht über die Interpretation von XML).

Ich habe dies ziemlich offen für Interpretationen gelassen, da ich an dieser Stelle nichts ausschließen möchte, indem ich spezifischer bin.

Irgendwelche Ideen geschätzt!

Answer 1

Ich habe dies vor einer Weile für eine große Regierung Business Rules Engine.

Mithilfe des XML-Schemas zur Beschreibung der Daten habe ich mithilfe von XML-Schemaanmerkungen alle für die Engine spezifischen Bits hinzugefügt, um sicherzustellen, dass das Schema gültig bleibt.

Die GUI bietet eine traditionelle Ansicht im Explorer-Stil mit einer Strukturansicht, die die Struktur zeigt, und dem rechten Bereich, der die Details für den ausgewählten Baumknoten anzeigt.

Ich habe einige ziemlich komplexe XSLT (mit einigen benutzerdefinierten Erweiterungen) verwendet, um ein kleines XML-Dokument zu generieren, das ein Formular und eine kleine Engine darstellt, die die Steuerelemente dynamisch aus dieser Formulardefinition rendert.

Der Code hinter dem Formular aktualisiert ein XML-Fragment, das dann von einem anderen Teil von XSLT in ein XML-Diffgramm zurückübersetzt und zum Aktualisieren der speicherinternen Darstellung des Schemas verwendet wird.

Sobald das mit Annotationen versehene XML-Schema erstellt wurde, erzeugte ein Compiler zwei .NET-Assemblys, von denen eine eine Codedarstellung des Schemas und die andere die Implementierung der Geschäftsregeln enthielt.

Es war ein ziemlich komplexes Stück Code, aber einer, der sehr flexibel und dynamisch war und die große Mehrheit der Benutzeroberfläche konnte durch XSLT allein angepasst werden. Tatsächlich benötigten einige Benutzer verschiedene Ansichten, die vollständig über eine zusätzliche dynamisch geladene Assembly behandelt wurden, die XSLT enthielt.

Kosten rund 2,5 Mio. GBP und dauerte über zwei Jahre zu entwickeln, mind (die ganze Sache, nicht nur die Benutzeroberfläche). Es ist die Entwicklung, auf die ich in meinen 28 Jahren in der Branche am meisten stolz war!

Gerne weiter zu besprechen, wenn Sie wollen.

Answer 2

Werfen Sie einen Blick auf die Regeln und Ausdrücke Designer der Regel-Engine in Windows Workflow Foundation. Sie sollen beide außerhalb von Visual Studio hostbar sein. Insbesondere habe ich ein Beispiel gesehen, in dem der Regel-Designer einen bestimmten Typ als Kontext übergeben hat und in der Lage war, Regeln und Ausdrücke auf der Grundlage der Eigenschaften dieses Typs und der Typen zu erstellen, auf die diese Eigenschaften verweisen.Tatsächlich war es möglich, einen Typ an der Wurzel eines Objektdiagramms zu übergeben, und die Engine konnte dann mit den Eigenschaften aller Objekte im Diagramm arbeiten.