it-swarm.com.de

Sollte ich eine Konfigurationsdatei oder Datenbank zum Speichern von Geschäftsregeln verwenden?

Ich habe kürzlich The Pragmatic Programmer gelesen, in dem es heißt:

Details bringen unseren makellosen Code durcheinander - besonders wenn sie sich häufig ändern. Jedes Mal, wenn wir den Code ändern müssen, um Änderungen in der Geschäftslogik, im Gesetz oder im persönlichen Geschmack des Managements Rechnung zu tragen, laufen wir Gefahr, das System zu beschädigen - einen neuen Fehler einzuführen.

Hunt, Andrew; Thomas, David (1999-10-20). Der pragmatische Programmierer: Vom Gesellen zum Meister (Kindle Locations 2651-2653). Pearson Education (USA). Kindle Edition.

Ich programmiere derzeit eine Web-App mit einigen Modellen, deren Eigenschaften nur aus einer Reihe von Werten stammen können, z. (kein aktuelles Beispiel, da die Web-App-Daten vertraulich sind):

licht-> Typ = Kugel/Würfel/Zylinder

Der Lichttyp kann nur die obigen drei Werte sein, aber laut TPP sollte ich immer so codieren, als ob sie ihre Werte ändern und in eine Konfigurationsdatei einfügen könnten. Da es in der gesamten App mehrere Vorfälle gibt, lautet meine Frage:

Sollte ich möglicherweise Werte wie diese speichern in:

  • eine Konfigurationsdatei:
    'light-types' => array(sphere, cube, cylinder),
    'other-type' => value,
    'etc' => etc-value

  • eine einzelne Tabelle in einer Datenbank mit einer Zeile für jedes Konfigurationselement

  • eine Datenbank mit einer Tabelle für jedes Konfigurationselement (z. B. Tabelle: light_types; Spalten: id, name)

  • auf andere Weise?

Vielen Dank für jede Unterstützung/Expertise angeboten.

42
foiseworth

Die gleiche Frage stellt sich bei den meisten Projekten, an denen ich arbeite. Normalerweise mache ich das:

  1. Wenn es unwahrscheinlich ist, dass sich die Menge der möglichen Werte bald ändert, verwende ich Klassen-/Schnittstellenkonstanten oder Aufzählungen im Code und Aufzählungsfelder in der Datenbank. Beispiel: Veröffentlichungsstatus von Blogeinträgen: "nicht veröffentlicht", "unter Moderation", "veröffentlicht" usw.
  2. Die Werte werden sich wahrscheinlich ändern, aber Änderungen wirken sich nicht auf die Programmlogik - Konfigurationsdateien aus. Beispiel: Liste von "Wie haben Sie unsere Website gefunden?" Optionen für eine Dropdown-Liste im Online-Kaufformular.
  3. Es ist wahrscheinlich, dass sich Werte häufig ändern und/oder von Nicht-Entwicklern bearbeitet werden sollen. Diese Änderungen wirken sich jedoch nicht auf die Logik aus - eine Datenbank oder zumindest einen Schlüsselwertspeicher mit einer benutzerfreundlichen Oberfläche zum Bearbeiten.
  4. Das Ändern der Werte wirkt sich auf die Logik aus - wahrscheinlich muss das System neu gestaltet werden (häufig wahr) oder es wird eine Engine für Geschäftsregeln benötigt. Der schwierigste Fall, den ich bisher gesehen habe, war der Konstruktor für psychologische Tests, an dem mein Kollege gearbeitet hat. Jede Art von Test kann ein eigenes Bewertungssystem haben, das von der einfachen Hinzufügung zu mehreren Merkmalsskalen mit positiven und negativen Werten oder sogar der menschlichen Bewertung von Antworten variieren kann. Nach einigen Diskussionen über dieses Projekt haben wir Lua als Skript-Engine verwendet, was völlig im Widerspruch zur Fähigkeit von Nicht-Entwicklern steht, neue Tests zu erstellen (obwohl Lua eine relativ einfache Sprache ist, die Sie nicht sollten). Ich erwarte nicht, dass ein Nicht-Programmierer es lernen wird.

Über das Zitat von TPP. Ich denke, es gilt für makellosen Code, aber im wirklichen Leben sollten Sie einfach ( KISS-Prinzip ) beginnen und später Funktionen hinzufügen wenn sie wirklich gebraucht werden ( YAGNI ).

45
scriptin

Wenn sich Ihre Daten in einer Datenbank befinden, würde ich empfehlen, eine Tabelle mit 'light_types' in derselben Datenbank zu haben. Auf diese Weise können Sie Fremdschlüssel verwenden, um eine Einschränkung zu erzwingen, dass light-> type nur einer dieser Werte sein kann. Selbst wenn der Code fehlerhaft ist, sind die Daten in der Datenbank immer gültig.

Wenn die Daten nicht in einer Datenbank gespeichert werden, hilft es nicht viel, eine nur für eine Reihe von Aufzählungen zu erstellen. Ich könnte eine Konfigurationsdatei empfehlen, wenn Sie wirklich vermeiden möchten, die Werte fest zu codieren.

(Ich würde jedoch davor warnen, zu weit zu gehen, um Hardcodierung zu vermeiden. In jedem nicht trivialen System gibt es Annahmen über Geschäftsregeln und -anforderungen, ob die Autoren dies realisieren oder nicht. Selbst wenn Sie es irgendwie schaffen, alles zu vermeiden Annahmen und Softcode absolut alles, Sie haben im Grunde nur eine "Regel-Engine", eine Art System innerhalb eines Systems und/oder Metasprache, und Sie haben eine Menge Dinge in der Metasprache zu tun Implementieren Sie die Regeln. Sie haben keine Arbeit gespeichert oder Flexibilität gewonnen. Sie mussten lediglich eine andere Sprache erstellen und/oder lernen.

Wenn Sie nun eine vorhandene Regelengine suchen und verwenden möchten, kann that Ihnen ein wenig Arbeit ersparen (zusammen mit der Beantwortung der Frage, wo Aufzählungen gespeichert werden sollen). Aber das Erstellen eines eigenen Systems verdoppelt nur die Arbeitsbelastung und bringt Ihnen unweigerlich ein halbherziges System, das von Leuten gebaut wurde, die wirklich nicht wissen, wie man eine anständige Regel-Engine erstellt.)

7
cHao

Im Allgemeinen sollte eine Datenbank für Daten und eine Konfigurationsdatei für die Konfiguration verwendet werden. (wie der Name schon sagt :)). Das Beibehalten der Konfiguration in der Datenbank ist eine schlechte Trennung von Bedenken und sollte nur durchgeführt werden, wenn Sie einen guten Anwendungsfall haben, um dies zu rechtfertigen.

Bei der Entscheidung, wie viel Konfiguration verwendet werden soll, muss ein Gleichgewicht hergestellt werden. Sie sollten Ihre Konfigurationsdateien genauso als Teil einer Anwendung wie den Code behandeln. Halte es so knapp wie möglich. Es ist sehr einfach für Anwendungen, unter Konfigurationsschwankungen zu leiden, bei denen Sie eine riesige XML-Datei voller magischer Zeichenfolgen erhalten.

In dem von Ihnen beschriebenen Fall wäre es sinnvoll, ein Konfigurationselement zu haben, um zu definieren, welche CSS-Datei verwendet werden soll. (Sie können es dann einfach ändern, wenn sich die Anforderungen ändern). Es wäre übertrieben, den Stil jedes Elements in der Konfigurationsdatei zu konfigurieren

0
Tom Squires