Wann sollten Sie keine Rules -Engine verwenden? [abgeschlossen

Question

Ich habe eine ziemlich anständige Liste der Vorteile der Verwendung einer Regeln -Engine sowie einige Gründe, sie zu verwenden. Ich brauche eine Liste der Gründe, warum Sie keine Regeln -Engine verwenden sollten

Das Beste, was ich bisher habe, ist Folgendes:

Regeln -Motoren sind nicht wirklich beabsichtigt, Workflow- oder Prozessausführungen zu verarbeiten, noch sind Workflow -Engines oder Prozessmanagement -Tools, die Regeln durchführen.

Irgendwelche anderen großen Gründe, warum Sie sie nicht verwenden sollten?

Answer 1

Ich werde sehr nervös, wenn ich Leute sehe, die sehr große Regelsätze verwenden (z. B. in der Größenordnung von Tausenden von Regeln in einem einzigen Regelsatz). Dies geschieht oft, wenn der Rules -Engine ein Singleton ist, der in der Mitte des Unternehmens sitzt, in der Hoffnung, dass die Regeln behalten TROCKEN wird sie für viele Apps zugänglich machen, die sie erfordern. Ich würde mich jedem widersetzen, um mir zu sagen, dass ein RETE-Regeln mit so vielen Regeln gut verstanden ist. Mir ist keine Tools bekannt, die überprüfen können, ob Konflikte nicht bestehen.

Ich denke, Partitionierungsregeln, um sie klein zu halten, ist eine bessere Option. Aspekte können eine Möglichkeit sein, einen gemeinsamen Regelsatz unter vielen Objekten zu teilen.

Ich bevorzuge einen einfacheren, datengetriebeneren Ansatz, wo immer möglich.

Answer 2

Ich werde 2 Beispiele aus persönlicher Erfahrung geben, bei denen die Verwendung einer Regeln eine schlechte Idee war, vielleicht hilft das:-

1. Bei einem früheren Projekt stellte ich fest, dass die Regeln -Dateien (das Projekt, das Sabrikum verwendete) viele Java -Code enthielt, einschließlich Schleifen, Funktionen usw. Es handelte sich im Wesentlichen um Java -Dateien, die als Regelndatei tarnen. Als ich den Architekt nach seiner Argumentation für das Design fragte, wurde mir mitgeteilt, dass die "Regeln nie von Geschäftsnutzern gepflegt werden sollen".

Lektion: Sie werden aus einem bestimmten Grund als "Geschäftsregeln" bezeichnet. Verwenden Sie keine Regeln, wenn Sie kein System entwerfen können, das von Geschäftsnutzern leicht verwaltet/verstanden werden kann.

2. Ein anderer Fall; Das Projekt verwendete Regeln, weil die Anforderungen schlecht definiert/verstanden und häufig verändert wurden. Die Lösung des Entwicklungsteams bestand darin, Regeln ausgiebig zu verwenden, um häufige Code -Bereitstellungen zu vermeiden.

Lektion: Die Anforderungen ändern sich in der Regel bei den ersten Änderungen der Erstveröffentlichung stark und rechtfertigen nicht die Verwendung von Regeln. Verwenden Sie Regeln, wenn sich Ihr Unternehmen häufig ändert (nicht Anforderungen). ZB:- Eine Software, die Ihre Steuern jedes Jahr ändert, wenn sich die Steuergesetze ändern und die Verwendung von Regeln eine hervorragende Idee ist. Release 1.0 einer Web -App ändert sich häufig, wenn Benutzer neue Anforderungen identifizieren, sich jedoch im Laufe der Zeit stabilisieren. Verwenden Sie keine Regeln als Alternative zur Code -Bereitstellung.

Answer 3

Ich bin ein großer Fan von Business Rules Engines, da es Ihnen helfen kann, Ihr Leben als Programmierer viel einfacher zu machen. Eine der ersten Erfahrungen, die ich bei der Arbeit an einem Data Warehouse -Projekt gemacht habe, war es, gespeicherte Verfahren zu finden, die komplizierte Fallstrukturen enthalten, die sich über ganze Seiten erstrecken. Es war ein Albtraum zum Debuggen, da es sehr schwierig war, die in so lange Fallstrukturen angewendete Logik zu verstehen, und um festzustellen, ob Sie eine Überlappung zwischen einer Regel auf Seite 1 des Codes und einer anderen von Seite 5 haben Mehr als 300 solcher Regeln, die in den Code eingebettet sind.

Als wir eine neue Entwicklungsanforderung für etwas als Buchhaltungsziel erhalten haben, das mehr als 3000 Regeln behandelte, wusste ich, dass sich etwas ändern musste. Damals habe ich an einem Prototyp gearbeitet, der später der Elternteil einer benutzerdefinierten Geschäftsregel -Engine ist, die alle SQL -Standardbetreiber bearbeiten kann. Zunächst haben wir Excel als Autoring -Tool verwendet und später eine ASP.NET -Anwendung erstellt, mit der die Geschäftsbenutzer ihre eigenen Geschäftsregeln definieren können, ohne dass Code geschrieben werden muss. Jetzt funktioniert das System gut mit sehr wenigen Fehler und enthält über 7000 Regeln für die Berechnung dieses Buchhaltungsziels. Ich glaube nicht, dass ein solches Szenario nur durch hartkodierende Kodierung möglich gewesen wäre. Und die Benutzer sind ziemlich froh, dass sie ihre eigenen Regeln definieren können, ohne dass dies zu ihrem Engpass wird.

Ein solcher Ansatz hat jedoch Grenzen:

• Sie müssen fähige Geschäftsanwender haben, die ein hervorragendes Verständnis für das Unternehmensgeschäft haben.
• Bei der Suche des gesamten Systems (in unserem Fall ein Data Warehouse) gibt es eine erhebliche Arbeitsbelastung, um alle hartcodierten Bedingungen zu bestimmen, die sinnvoll sind, in Regeln umzusetzen, die von einer Geschäftsregel-Engine behandelt werden sollen. Wir mussten uns auch darauf achten, dass diese anfänglichen Vorlagen von Geschäftsnutzern vollständig verständlich sind.
• Sie benötigen eine Anwendung für das Verfassen von Regeln, bei dem Algorithmen zur Erkennung überlappender Geschäftsregeln implementiert werden. Andernfalls werden Sie ein großes Chaos haben, bei dem niemand mehr die Ergebnisse versteht, die er erzielt. Wenn Sie einen Fehler in einer generischen Komponente wie eine benutzerdefinierte Geschäftsregel -Engine haben, kann es sehr schwierig sein, um umfangreiche Tests zu debugieren, um sicherzustellen, dass die Dinge, die zuvor funktionieren, jetzt auch funktionieren.

Weitere Details zu diesem Thema finden Sie in einem Beitrag, den ich geschrieben habe: http://dwhbp.com/post/2011/10/30/implementing-a-business-rule-gine.aspx

Insgesamt besteht der größte Vorteil der Verwendung eines Geschäftsregelmotors darin, dass die Benutzer die Kontrolle über die Geschäftsregeldefinitionen und das Autoring zurücknehmen können, ohne dass sie bei jeder Änderung der IT -Abteilung an die IT -Abteilung gehen müssen. Es reduziert auch die Arbeitsbelastung über IT -Entwicklungsteams, die sich nun darauf konzentrieren kann, Dinge mit mehr Mehrwert zu erstellen.

Prost,

Nicolae

Answer 4

Der eine Poit, das mir als "das doppelt geschnittene Schwert" aufgefallen ist, ist:

Platzierung der Logik in die Hände von Nicht -technischem Personal

Ich habe diese Arbeit hervorragend gesehen, wenn Sie ein oder zwei multidisziplinäre Genies auf der nicht technischen Seite haben, aber ich habe auch die mangelnde Technik gesehen, die zu Aufblähen, mehr Bugs und im Allgemeinen 4 -fachen die Entwicklungs-/Wartungskosten führt.

Daher müssen Sie Ihre Benutzerbasis ernst betrachten.

Answer 5

Ich dachte, Alex Papadimoulis 'Artikel sei ziemlich aufschlussreich: http://thedailywtf.com/articles/soft_coding.aspx

Es ist nicht umfassend, aber er hat einige gute Punkte.

Answer 6

Toller Artikel darüber, wenn Sie keine Regeln -Engine verwenden ... (und wann Sie eines verwenden können) ....

http://www.jessrules.com/guidelines.shtml

Eine andere Option ist, wenn Sie eine lineare Reihe von Regeln haben, die nur einmal in beliebiger Bestellung gelten, um ein Ergebnis zu erzielen, besteht darin, eine groovige Schnittstelle zu erstellen und Entwickler diese neuen Regeln zu schreiben und bereitzustellen. Der Vorteil ist, dass es böse schnell ist, da Sie normalerweise die Hibernate -Sitzung oder die JDBC -Sitzung sowie alle Parameter übergeben, damit Sie Zugriff auf alle Ihre Apps -Daten haben, jedoch auf effiziente Weise. Mit einer Tatsachenliste kann eine Menge Schleifen/Übereinstimmungen vorhanden sein, die das System wirklich verlangsamen können. Datenbank und wir hatten keine Rekursion .... sie hat entweder die Regel erfüllt oder nicht). Es ist nur eine weitere Option ..... Oh und ein weiterer Vorteil ist die Lernregeln -Syntax für eingehende Entwickler. Sie müssen etwas groovig lernen, aber das ist Java sehr nahe, daher ist die Lernkurve viel besser.

Es hängt wirklich von Ihrem Kontext ab. Rules Engine hat ihren Platz und das oben genannte ist nur eine weitere Option, wenn Sie Regeln für ein Projekt haben, die Sie möglicherweise dynamisch für sehr vereinfachte Situationen bereitstellen möchten, in denen keine Regeln -Engine erforderlich sind.

Verwenden Sie im Grunde keine Rules -Engine, wenn Sie einen einfachen Regeln haben und stattdessen über eine groovige Schnittstelle verfügen können. So wie es dynamisch einsetzbar ist und neue Entwickler, die sich Ihrem Team anschließen, schneller lernen können als die Sprache der Sabrools.

Answer 7

Nach meiner Erfahrung funktionieren Regeln Motoren am besten, wenn Folgendes wahr ist:

1. Eine genau definierte Doktrin für Ihre Problemdomäne
2. Hochwertige (vorzugsweise automatisierte) Daten, die dazu beitragen, die meisten Ihrer Eingaben zu treiben
3. Zugang zu Experten von Fache
4. Softwareentwickler mit Erfahrung Erstellen von Expertensystemen

Wenn eine dieser vier Merkmale fehlt, finden Sie möglicherweise immer noch eine Regeln, die Motor für Sie funktioniert, aber jedes Mal, wenn ich es versucht habe, wenn ich nur 1 fehlt, habe ich in Schwierigkeiten geraten.

Answer 8

Das ist sicherlich ein guter Anfang. Die andere Sache mit Regeln Motoren ist, dass einige Dinge gut verstanden, deterministisch und unkompliziert sind. Das Zurückhalten von Lohn- und Gehaltsabrechnungen ist so (oder verwendet) so. Du könnte Drücken Sie es als Regeln aus, die von einer Regeln -Engine gelöst werden, aber Sie könnten dieselben Regeln wie eine ziemlich einfache Werte Tabelle ausdrücken.

Workflow-Motoren sind also gut, wenn Sie einen längerfristigen Prozess ausdrücken, der anhaltende Daten aufweist. Regelnmotoren können etwas Ähnliches tun, aber Sie müssen eine Menge zusätzlicher Komplexität machen.

Regeln Motoren sind gut, wenn Sie komplizierte Wissensbasis haben und suchen müssen. Regelnmotoren können komplizierte Probleme lösen und schnell an sich ändernde Situationen angepasst werden, aber der Basisimplementierung viel Komplexität auferlegen.

Viele Entscheidungsalgorithmen sind einfach genug, um als einfaches, Tabellengesteuerter Programm ohne die Komplexität auszudrücken, die durch eine reale Regeln-Engine impliziert wird.

Answer 9

Ich würde dringend geschäftliche Regelnem Enginen mögen wie Sabber als Open Source oder Kommerzielle Regeln Motor wie Liveruli.

• Wenn Sie viele Geschäftspolitiken haben, die volatiler Natur sind, ist es sehr schwierig, diesen Teil des Kerntechnologiecode zu erhalten.
• Die Rules Engine bietet eine große Flexibilität des Frameworks und leicht zu ändern und bereitzustellen.
• Regelnmotoren dürfen nicht überall verwendet werden, sondern müssen verwendet werden, wenn Sie viele Richtlinien haben, bei denen Änderungen regelmäßig unvermeidlich sind.

Answer 10

Ich verstehe einige Punkte wie:
a) Geschäftsleute müssen das Geschäft sehr gut verstehen oder;
b) Uneinigkeit über Geschäftsleute müssen die Regel nicht kennen.

Für mich ist der Vorteil von BRE als Volk, das nur Bre berührt, so berufen, das System an den Geschäftswandel anzupassen, und konzentriert sich daher auf die Anpassung der Veränderung.
Ist es wichtig, ob sich die zum Zeitpunkt x eingerichtete Regel von der zum Zeitpunkt y zum Zeitpunkt y unterscheidet::
a) Geschäftsleute verstehen das Geschäft nicht oder;
b) Geschäftsleute verstehen Regeln nicht?