web-dev-qa-db-fra.com

Dois-je utiliser un fichier de configuration ou une base de données pour stocker des règles métier?

J'ai récemment lu The Pragmatic Programmer qui déclare que:

Les détails gâchent notre code vierge, surtout s'ils changent fréquemment. Chaque fois que nous devons entrer et changer le code pour tenir compte d'un changement dans la logique métier, ou dans la loi, ou dans les goûts personnels de la direction de la journée, nous courons le risque de briser le système - d'introduire un nouveau bogue.

Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master (Kindle Locations 2651-2653). Pearson Education (États-Unis). Édition Kindle.

Je suis en train de programmer une application web qui a des modèles dont les propriétés ne peuvent provenir que d'un ensemble de valeurs, par ex. (pas un exemple réel car les données de l'application Web sont confidentielles):

lumière-> type = sphère/cube/cylindre

Le type de lumière ne peut être que les trois valeurs ci-dessus, mais selon TPP, je devrais toujours coder comme si elles pouvaient changer et placer leurs valeurs dans un fichier de configuration. Comme il y a plusieurs incidents de ce type dans l'application, ma question est:

Dois-je stocker éventuellement des valeurs comme celles-ci dans:

  • un fichier de configuration:
    'light-types' => array(sphere, cube, cylinder),
    'other-type' => value,
    'etc' => etc-value

  • une seule table dans une base de données avec une ligne pour chaque élément de configuration

  • une base de données avec une table pour chaque élément de configuration (par exemple table: light_types; colonnes: id, name)

  • d'une autre manière?

Merci beaucoup pour toute assistance/expertise offerte.

designdatabaseconfiguration
42
foiseworth

La même question se pose dans la plupart des projets sur lesquels je travaille. Habituellement, je fais ceci:

  1. S'il est peu probable que l'ensemble des valeurs possibles change prochainement, j'utilise des constantes ou des énumérations de classe/interface dans le code et les champs énumérables de la base de données. Exemple: état de publication des entrées de blog: "non publié", "en cours de modération", "publié", etc.
  2. Les valeurs changeront probablement, mais les changements n'affecteront pas la logique du programme - les fichiers de configuration. Exemple: liste de "comment avez-vous trouvé notre site Web?" options pour une liste déroulante sous forme d'achat en ligne.
  3. Les valeurs sont susceptibles de changer fréquemment et/ou censées être modifiées par des non-développeurs, mais pourtant ces modifications n'affecteront pas la logique - une base de données ou au moins un stockage de valeur-clé avec une interface conviviale pour l'édition.
  4. La modification des valeurs affectera la logique - le système a probablement besoin d'être repensé (souvent vrai) ou un moteur de règles métier est nécessaire. Le cas le plus difficile que j'ai vu jusqu'à présent était celui du constructeur de tests psychologiques sur lequel mon collègue a travaillé. Chaque type de test peut avoir son propre système de notation qui peut varier d'un simple ajout à plusieurs échelles de caractéristiques avec des valeurs positives et négatives ou même une évaluation humaine des réponses. Après quelques discussions sur ce projet, nous avons fini par utiliser Lua comme moteur de script, ce qui est totalement en conflit avec la capacité des non-développeurs à créer de nouveaux tests (même si Lua est un langage relativement simple, vous ne devriez pas '' t attendre qu'un non-programmeur l'apprenne).

À propos de la citation de TPP. Je pense que c'est vrai pour le code vierge , mais dans la vraie vie, il vaut mieux commencer simple ( principe KISS ) et ajouter des fonctionnalités plus tard s'ils sont vraiment nécessaires ( YAGNI ).

45
scriptin

Si vos données seront dans une base de données, je recommanderais d'avoir une table de 'light_types' dans la même base de données. Cela vous donne la possibilité d'utiliser des clés étrangères pour imposer une contrainte selon laquelle le type light-> ne peut être qu'une de ces valeurs, donc même si le code ne fonctionne pas, les données de la base de données seront toujours valides.

Si les données ne sont pas stockées dans une base de données, en créer une juste pour un tas d'énumérations ne fait pas beaucoup de bien. Je pourrais recommander un fichier de configuration, si vous voulez vraiment éviter de coder en dur les valeurs.

(Je vous déconseille cependant d'aller trop loin en évitant le codage en dur. Dans tout système non trivial, il y aura des hypothèses sur les règles et les exigences commerciales, que les auteurs s'en rendent compte ou non. Même si vous parvenez à éviter tout hypothèses et soft-code absolument tout, vous vous retrouvez simplement avec un "moteur de règles", une sorte de système dans un système et/ou un méta-langage, et vous avez un tas de trucs dans le méta-langage pour Vous n'avez pas enregistré de travail ni gagné en flexibilité, il vous suffit de construire et/ou d'apprendre une autre langue.

Maintenant, si vous voulez trouver et utiliser un moteur de règles existant, que pourrait vous faire économiser un peu de travail (tout en répondant à la question de savoir où stocker les énumérations). Mais la construction de la vôtre double simplement la charge de travail et vous procure inévitablement un système à moitié construit par des gens qui ne savent vraiment pas comment créer un moteur de règles décent.)

7
cHao

En général, une base de données doit être utilisée pour les données et un fichier de configuration doit être utilisé pour la configuration. (comme le nom le suggère :) ). Conserver la configuration dans la base de données est une mauvaise séparation des préoccupations et ne doit être effectué que si vous avez un bon cas d'utilisation pour le justifier.

Il y a un équilibre à trouver pour décider de la configuration à utiliser. Vous devez traiter vos fichiers de configuration autant comme faisant partie d'une application que le code. Gardez-le aussi concis que possible. Il est très facile pour les applications de souffrir de ballonnements de configuration où vous vous retrouvez avec un énorme fichier xml plein de chaînes magiques.

Dans le cas que vous décrivez, il serait raisonnable d'avoir un élément de configuration pour définir le fichier CSS à utiliser. (vous pouvez ensuite le modifier si les exigences changent). Il serait exagéré de configurer le style de chaque élément dans le fichier de configuration

0
Tom Squires