Devrais-je utiliser un fichier de configuration ou une base de données pour stocker les règles de gestion?

Je lisais récemment The Pragmatic Programmer qui dit que:

Les détails bousillent notre code vierge, surtout s'ils changent fréquemment. Chaque fois que nous devons modifier le code pour tenir compte de certains changements dans la logique commerciale, dans la loi ou dans les goûts personnels de la direction, nous risquons de casser le système - de créer un nouveau bogue.

Hunt, Andrew; Thomas, David (1999-10-20). Le programmeur pragmatique: de compagnon à maître (Emplacements Kindle 2651-2653). Pearson Education (États-Unis). Édition Kindle.

Je programme actuellement une application Web dont certains modèles ont des propriétés qui ne peuvent provenir que d'un ensemble de valeurs, par exemple (il ne s'agit pas d'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 le PPT, 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 la suivante:

Devrais-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 de la table: light_types;: colonnes id, name)

• d'une autre manière?

Merci beaucoup pour toute aide / expertise offerte.

La même question se pose dans la plupart des projets sur lesquels je travaille. D'habitude, je fais ça:

1. S'il est peu probable que l'ensemble des valeurs possibles change dans un avenir rapproché, j'utilise des constantes ou des énumérations de classe / interface dans le code et des champs énumérables dans la base de données. Exemple: état de publication des entrées de blog: "non publié", "en modération", "publié", etc.
2. Les valeurs vont probablement changer, 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 dans le formulaire d'achat en ligne.
3. Les valeurs sont susceptibles de changer fréquemment et / ou d'être éditées par des non-développeurs, mais ces modifications n'affecteront pas la logique - une base de données ou au moins un stockage clé-valeur avec une interface utilisateur conviviale pour l'édition.
4. La modification des valeurs aura une incidence sur la logique - il est probable que le système a besoin d'une nouvelle conception (souvent vrai) ou qu'un moteur de règles métier soit nécessaire. Le cas le plus difficile que j'ai vu jusqu'à présent était celui des tests psychologiques auxquels mon collègue a travaillé. Chaque type de test peut avoir son propre système de notation qui peut aller de la simple addition à 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 finalement utilisé Lua comme moteur de script, ce qui est en totale contradiction 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 vous attendre à ce que l'apprendra).

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

Si vos données seront dans une base de données, je vous recommande d'avoir une table de 'light_types' dans le même DB. Cela vous donne la possibilité d'utiliser des clés étrangères pour appliquer une contrainte, que light-> type ne peut être qu'une de ces valeurs. Ainsi, même si le code échoue, 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'énums ne fait pas beaucoup de bien. Je recommanderais peut-être un fichier de configuration si vous voulez vraiment éviter de coder en dur les valeurs.

(Je vous déconseille toutefois d'aller trop loin en évitant de coder en dur. Dans tout système non trivial, il y aura des hypothèses sur les règles et exigences commerciales, que les auteurs s'en rendent compte ou non. suppositions et soft-code absolument tout, vous vous retrouvez avec un "moteur de règles", une sorte de système dans un système et / ou de méta-langage, et vous avez un tas de choses dans le méta-langage pour mettre en œuvre les règles: vous n’avez enregistré aucun travail ni gagné en flexibilité, vous devez simplement construire et / ou apprendre une autre langue.

Désormais, si vous souhaitez rechercher et utiliser un moteur de règles existant, vous épargnerez peut - être un peu de travail (tout en répondant à la question de savoir où stocker les énumérations). Mais créer votre propre système double simplement la charge de travail et vous procure inévitablement un système à moitié construit par des personnes qui ne savent vraiment pas comment créer un moteur de règles décent.)

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

Il faut trouver un équilibre pour décider de la configuration à utiliser. Vous devriez traiter vos fichiers de configuration autant que le code d’une partie d’une application. Gardez-le aussi bref que possible. Il est très facile pour les applications de souffrir de problèmes de configuration, où vous vous retrouvez avec un énorme fichier XML rempli 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 alors simplement le changer si les exigences changent). Il serait excessif de configurer le style de chaque élément du fichier de configuration