Darstellung von Geschäftsregeln mit Ausnahmen

Ich weiß, dass es teuer ist, aber (IMO) ich glaube, dass es eine sehr gute Praxis ist. Ich spreche von Regeln wie zum Beispiel: Sie können keine Rechnung speichern, wenn Sie kein Verkäufer sind. In diesem Fall wird eine Ausnahme ausgelöst, die besagt, dass Sie nicht autorisiert sind.

Ein anderer Ansatz wäre, Objekte mit einem Status oder ähnlichem zu haben

Gibt es einen anderen Ansatz? wie stehen Sie dazu?

Wenn Sie damit meinen, einzelne Geschäftsregelprüfungen mit Ausnahmen darzustellen, halte ich das nicht für eine sehr gute Idee. Oft müssen Sie mehr als eine ausgefallene Bedingung melden und müssen nicht bei der ersten aufhören.

Andererseits glaube ich, dass es eine gute Praxis ist, alle Regeln zu überprüfen und dann eine Ausnahme mit der Zusammenfassung auszulösen.

In dem Beispiel, das Sie uns gegeben haben, halte ich das Auslösen einer Ausnahme für eine schlechte Idee. Wenn Sie wissen, dass der Benutzer vor Arbeitsbeginn nicht autorisiert ist und Sie ihm dennoch erlauben, eine Funktion auszuführen, und ihn dann mit einer Meldung schlagen, nachdem er die Aufgabe bereits abgeschlossen hat, ist dies nur ein schlechtes Design.

Die Verwendung von Ausnahmen zur Durchsetzung von Geschäftsregeln ist kein gutes Konzept.

Ich verstehe nicht, welchen Wert das Auslösen einer Ausnahme für die Erstellung einer guten Geschäftslogik hat. Es gibt Dutzende von Ansätzen zur Handhabung von Geschäftslogik, bei denen kein System verwendet wird, mit dem unerwartete Bedingungen beim Betrieb eines Systems behoben werden können.

Es wird erwartet dass in der Geschäftslogik die Bedingungen nicht erfüllt werden. Das ist der Grund dafür, dass es an erster Stelle steht, und Sie möchten nicht auf denselben Mechanismus zurückgreifen, der unerwartete E / A-Fehler, Speicherfehler und Nullreferenzen behandelt. Dies sind Systemfehler, aber das Erkennen nicht erfüllter Geschäftsbedingungen ist der erfolgreiche Betrieb des Systems.

Darüber hinaus ist es ein System, das für unbeabsichtigte Konsequenzen reif ist. Da eine Ausnahme irgendwann abgefangen werden muss, besteht die Gefahr, dass eine neue Geschäftsregel-Ausnahme abgefangen wird, die nicht beabsichtigt ist, oder dass der Code nach Geschäftsregeln sucht, die Ausnahmen abfangen, die eigentlich nicht beabsichtigt sind dafür. Ja, diese Bedingungen können mit guten Codierungspraktiken berücksichtigt werden, aber in jedem nicht trivialen System, an dem mehr als ein Entwickler arbeitet, treten Fehler auf, und Sie müssen nur hoffen, dass es sich nicht um kostspielige Fehler handelt.

Geschäftsregeln auszudrücken ist eine Sache, sie umzusetzen eine andere

Denken Sie an die Benutzererfahrung. wenn der Benutzer nicht ein Verkäufer ist, warum sie einen Knopf geben , die ‚Rechnung erstellen‘ , sagt überhaupt ?

Das hängt ganz davon ab, was getan wird.

Was ist das tatsächliche Verhalten, das Sie wollen? Wenn jemand seine eigenen Informationen eingibt, ist eine Ablehnung und ein Dialogfeld mit der Meldung "Das können Sie nicht" wahrscheinlich korrekt. Wenn es sich um eine Dateneingabeperson handelt, die von einem Stapel von Formularen aus arbeitet, ist wahrscheinlich auch ein Dialogfeld hilfreich, und die Dateneingabeperson kann die ungültigen Formulare in einem speziellen Stapel ablegen. Wenn Sie die Stapelverarbeitung ausführen, möchten Sie die Dinge nicht zum Stillstand bringen, sondern sie markieren und zum nächsten übergehen.

Sobald Sie das Verhalten kennen, müssen Sie entscheiden, wie Sie es implementieren möchten. Ein Business Rules Checker, der eine Ausnahme auslöst, ist wahrscheinlich eine gute Idee. Das Zurückgeben und Weitergeben eines Rückkehrcodes kann auch schief gehen, und Sie möchten mit Sicherheit nicht, dass die fehlerhaften Eingaben weitergeleitet werden.

Sorgen Sie sich nicht um Leistungskosten. Im Falle einer Person, die Daten eingibt, ist dies im Vergleich zu den anderen beteiligten Zeiten trivial. Typischerweise wird der Mensch in diesem System die meiste Zeit in Anspruch nehmen. Wenn bei einem Batch-Job Ausnahmen ein Leistungsproblem darstellen, geben Sie viel zu viele fehlerhafte Datensätze ein, und in Wirklichkeit ist die Behandlung und erneute Eingabe all dieser Datensätze ein größeres Problem als die Ausnahmen.

Es ist sehr angemessen, eine robuste und gut gestaltete Ausnahme-API zu haben, die konsistent ist. Dies zur Durchsetzung von Geschäftsregeln zu verwenden, kann ebenfalls angemessen sein. Meiner Erfahrung nach ist es umso wahrscheinlicher, dass die Geschäftsregel so gehandhabt wird, je komplizierter sie ist. Es ist oft genauso einfach, wenn nicht sogar einfacher, ein System zu schreiben, in dem Ausnahmen erwartet werden, als autorisierende Verzweigungslogik zu schreiben.

Dies bedeutet, dass einfache Regeln, die in einem Satz beschrieben werden können, in der Regel präventiv oder autoritativ implementiert werden sollten, je nachdem, um welche es sich handelt. Wenn Sie jedoch eine mehrdimensionale Regel haben, für die mehr als drei oder vier Faktoren erforderlich sind (insbesondere, wenn die Auswahl dieser Faktoren auf einem oder mehreren der anderen Faktoren basiert), kann die Ausnahmecodierung möglicherweise besser verwaltet werden. In diesen Fällen müssen auf dem Logikpfad häufig Vorgängerausnahmen ausgelöst werden (es wird geprüft, warum die Aktion nicht ausgeführt werden kann), und dann (oder umgekehrt) wird die Sicherheit beeinträchtigt (um zu überprüfen, ob die Aktion autorisiert ist) ), manchmal gibt es eine autorisierende Akkumulationslogik, die überprüft werden muss (Verfügbarkeit von Nachkommen / Vorfahren, Vorläuferstatus, in den Objekte eingefügt werden müssen, usw.

Ein Vorteil dieser Art der Ausnahmebedingung besteht darin, dass Sie die Vorläuferausnahmen in mehreren Bereichen Ihres Projekts trennen und wiederverwenden können. (Dies ist die Essenz der aspektorientierten Programmierung.) Auf diese Weise kapseln Sie einen bestimmten Aspekt Ihrer allgemeinen Geschäftsregeln in einer eigenständigen und wartbaren Komponente. Im Allgemeinen entsprechen diese Komponenten 1-1 den ausgegebenen Fehlermeldungen. (Obwohl Sie manchmal eine Komponente haben, die mehrere verschiedene Ausnahmen auslöst, sollten Sie fast nie dieselbe Ausnahme von mehreren Komponenten auslösen.)

Meiner Meinung nach ist es schwieriger, Systeme zu entwerfen, die auf Ausnahmen basieren, und die anfängliche Entwicklungszeit ist länger, da Sie den Ausnahmevorgang über alle N Ebenen hinweg erstellen müssen. Im Allgemeinen sind diese Systeme jedoch wesentlich stabiler. Während es niemals möglich ist, ein System zu entwerfen, das nicht ausfällt, besteht der Vorteil eines ausnahmebasierten Entwurfs darin, dass Sie immer mit einem Ausfall rechnen. Für die meisten Menschen kann der Prozess kontraintuitiv sein. Es ist, als würde man nach dem Weg fragen und sich von jemandem sagen lassen, dass man nicht abbiegen sollte.