Devo utilizzare un file di configurazione o un database per archiviare le regole aziendali?

La stessa domanda sorge nella maggior parte dei progetti su cui lavoro. Di solito faccio questo:

1. Se è improbabile che l'insieme di valori possibili cambi presto, utilizzerò le costanti di classe / interfaccia nel codice e nei campi enumerabili nel database. Esempio: stato di pubblicazione di post di blog: "non pubblicato", "sotto moderazione", "pubblicato", ecc.
2. I valori probabilmente cambieranno, ma le modifiche non influenzeranno la logica del programma - i file di configurazione. Esempio: lista di "come hai trovato il nostro sito web?" opzioni per l'elenco a discesa nel modulo di acquisto online.
3. È probabile che i valori cambino frequentemente e / o siano destinati a essere modificati dai non sviluppatori, ma tuttavia queste modifiche non influiranno sulla logica: database con ORM o almeno archiviazione di valore chiave con qualche interfaccia user-friendly.
4. La modifica dei valori influisce sulla logica: probabilmente il sistema richiede una riprogettazione (spesso vera) o è necessario un motore di regole aziendali. Il caso più difficile che ho visto finora è stato il costruttore di test psicologici su cui lavorava il mio collega. Ogni tipo di test può avere il proprio sistema di punteggio che può variare da semplice aggiunta a più scale di caratteristiche con valori positivi e negativi o anche valutazione umana delle risposte. Dopo aver discusso di questo progetto, abbiamo utilizzato Lua come motore di scripting, che è totalmente in conflitto con la capacità dei non sviluppatori di creare nuovi test , anche conoscere Lua è un linguaggio molto semplice.

Informazioni sulla citazione da TPP. Penso che sia vero per il codice prestine , ma in vita reale (TM) è meglio iniziare in modo semplice (principio KISS) e aggiungere funzionalità in seguito se sono davvero necessarie (YAGNI) .

Mi sento sempre come se il codice potesse essere di prestigio solo se non si trova in un progetto su cui lavoro. E l'erba non è abbastanza verde ... Responsabili della colpa;)

Se i tuoi dati saranno in un database, ti consiglio di avere una tabella di "light_types" nello stesso DB. Questo ti dà la possibilità di usare chiavi esterne per imporre un vincolo che il tipo light > può essere solo uno di quei valori, quindi anche se il codice rovina, i dati nel DB saranno sempre validi.

Se i dati non verranno archiviati in un DB, crearne uno solo per un gruppo di enumerati non fa molto bene. Potrei raccomandare un file di configurazione, se vuoi davvero evitare di codificare i valori.

(Avrei messo in guardia dall'andare troppo lontano per evitare l'hard-coding, però. In qualsiasi sistema non banale, ci saranno ipotesi sulle regole e sui requisiti aziendali, indipendentemente dal fatto che gli autori lo capiscano o meno. per evitare tutte le ipotesi e il soft-code assolutamente tutto, in pratica si finisce semplicemente con un "motore delle regole", una sorta di sistema all'interno di un sistema e / o meta-linguaggio, e si ha un sacco di cose nella meta -language per implementare le regole. Non hai salvato alcun lavoro o guadagnato flessibilità, hai appena dovuto costruire e / o imparare un'altra lingua.

Ora, se vuoi trovare e utilizzare un motore di regole esistente, che potrebbe farti risparmiare un po 'di lavoro (oltre a rispondere alla domanda su dove archiviare le enumerazioni). Ma costruire il proprio raddoppia il carico di lavoro e ti porta inevitabilmente a un sistema semi-assed costruito da persone che non sanno davvero come creare un motore di regole decente.)

In generale un database dovrebbe essere usato per i dati e un file di configurazione dovrebbe essere usato per la configurazione. (Come suggerisce il nome :) ). Mantenere la configurazione nel database è una cattiva separazione delle preoccupazioni e dovrebbe essere fatto solo se si dispone di un buon caso d'uso per giustificarlo.

C'è un equilibrio da colpire quando si decide quanta configurazione usare. Dovresti trattare i tuoi file di configurazione tanto quanto una parte di un'applicazione come il codice. Tenerlo il più conciso possibile. È molto facile per le applicazioni soffrire di configurazione gonfia in cui si finisce con un enorme file xml pieno di stringhe magiche.

Nel caso in cui descrivi sarebbe ragionevole avere un elemento di configurazione per definire quale file css usare. (potresti quindi cambiarlo se cambiano i requisiti). Sarebbe eccessivo configurare lo stile di ogni elemento nel file di configurazione