Enum vs Config-Datei

Question

Wir möchten Geschäftslogik basierend auf Datensätzen in einer Tabelle implementieren. Wir haben zwei Möglichkeiten.

Eine Möglichkeit besteht darin, für jeden Datensatz in der Tabelle eine enum im Code zu erstellen und im Code die enum mit dem read-Datensatz zu vergleichen, um zu entscheiden, welche Logik als nächstes kommt. Ein Nachteil dieses Systems besteht darin, dass, wenn sich der Schlüssel in der Tabelle ändert (z. B. in Feldern mit automatischer Nummerierung), die Anwendung neu kompiliert werden muss, um Änderungen widerzuspiegeln. Eine zweite Möglichkeit besteht darin, Variablen in einer Konfigurationsdatei für jeden Datensatz in der Tabelle zu speichern und im Code die Konfigurationsvariable mit dem gelesenen Datensatz zu vergleichen, um zu entscheiden, welche Logik als nächstes kommt. Ein drwback mit diesem System ist, dass die Konfigurationsdatei manipuliert werden könnte und die Anwendung nicht mehr funktioniert.

Was ist das beste Programmiermuster für diese Angelegenheit?

Answer 1

Warum nicht alles zusammenhalten und eine Tabelle in die Datenbank schreiben, die Ihnen sagt, welche Tabelle der Geschäftsaufzeichnungen als nächstes kommt?

Sorry, ich kann keine bessere Antwort geben. Ich brauche mehr Informationen darüber, welche Dinge Ihre Geschäftslogik zu tun versucht, und welche Bestellungen diese Datensätze haben können.

Answer 2

Ich bevorzuge Ihren ersten Ansatz. Wenn sich die Logik ausreichend ändert, um eine Änderung an Ihrem Auto-Nummernfeld zu erfordern (entweder durch Löschen eines alten Datensatzes oder Hinzufügen eines neuen Datensatzes), müssen Sie den Code trotzdem ändern, um das neue Paradigma wiederzugeben.

Answer 3

Enums sollte statisch und unveränderlich sein. Wenn Sie eine Lösung haben, die zu einer Enumeration geändert werden muss, sind Enums die falsche Lösung.

Eine externe Konfiguration leidet unter den genannten Problemen, also ist es auch nicht immer eine gute Wahl. Um damit zu helfen, könnten Sie es verschlüsseln, so dass es nicht leicht modifizierbar ist.

Eine andere Alternative wäre, eine Ressource-DLL zu erstellen, die die Konfigurationsdatei als Ressource hat, so dass sie nicht leicht zu ändern ist. Wenn Sie eine Änderung vornehmen müssen, müssen Sie nur die Ressourcen-DLL kompilieren und nur diese und nicht die gesamte App bereitstellen.

Scott Langham erwähnte die Verwendung einer Konfigurationstabelle in Ihrer Datenbank. Dies ist auch eine gute Idee. Ist das mit deiner Einrichtung möglich?

Answer 4

Es klingt wie State-Muster. Ich stelle mir vor, dass Sie eine Tabelle haben, die Zustände (ID, Name) und Logik speichert, die jedem in Ihrer Anwendung zugeordnet sind. Eine gegebene Status-ID vorausgesetzt, muss die Logik ausgeführt werden. Sie müssen herausfinden, wie der korrekte Zustand instanziiert wird. Wenn Sie ein ORM verwenden, können Sie einen Diskriminator verwenden (in diesem Fall die Status-ID).