Riferimenti ai valori del database nella logica aziendale

Immagino che questa sia un'altra domanda sulla codifica e le migliori pratiche. Supponiamo di avere un elenco di valori, diciamo frutta, memorizzato nel database (deve essere nel database poiché la tabella viene utilizzata per altri scopi come i report SSRS), con un ID:

1 Apple 
2 Banana 
3 Grapes

Potrei presentarli all'utente, ne seleziona uno, viene memorizzato nel suo profilo come FavouriteFruit e l'ID memorizzato nel suo record nel database.

Quando si tratta di regole aziendali / logica di dominio, quali sono i consigli per assegnare la logica a valori specifici. Di 'se l'utente ha selezionato Uva Voglio svolgere qualche compito extra, qual è il modo migliore per fare riferimento al valore Uva:

// Hard coded name
if (user.FavouriteFruit.Name == "Grapes")

// Hard coded ID
if (user.FavoriteFruit.ID == 3) // Grapes

// Duplicate the list of fruits in an enum
if (user.FavouriteFruit.ID == (int)Fruits.Grapes)

o qualcos'altro?

Poiché, naturalmente, FavouriteFruit verrà utilizzato in tutta l'applicazione, l'elenco può essere aggiunto o modificato.

Qualcuno potrebbe decidere di voler rinominare 'Uva' in 'Uva' e questo ovviamente spezzerebbe l'opzione di stringa codificata.

L'ID hardcoded non è completamente chiaro, sebbene, come mostrato, potresti semplicemente aggiungere un commento per identificare rapidamente quale elemento è.

L'opzione enum comporta la duplicazione dei dati dal database che sembra errato in quanto potrebbe non essere sincronizzato.

Comunque, grazie in anticipo per eventuali commenti o suggerimenti.

Evita le stringhe e le costanti magiche a tutti i costi. Sono completamente fuori questione, non dovrebbero nemmeno essere considerati come opzioni. Questo sembra lasciarti con una sola opzione praticabile: identificatori, cioè enum. Tuttavia, c'è anche un'altra opzione, che secondo me è la migliore. Chiamiamo questa opzione "Oggetti precaricati". Con Oggetti precaricati, è possibile effettuare le seguenti operazioni:

if( user.FavouriteFruit.ID == MyApplication.Grape.ID )

Quello che è appena successo qui è che ho ovviamente caricato l'intera riga di Grapein memoria, quindi ho il suo ID pronto per l'uso nei confronti. Se stai utilizzando Object-Relational Mapping (ORM), sembra ancora meglio:

if( user.FavouriteFruit == MyApplication.Grape )

(Ecco perché lo chiamo "Oggetti precaricati".)

Quindi, quello che faccio è che durante l'avvio carico tutte le mie tabelle di "enumerazione" (piccole tabelle come i giorni della settimana, i mesi dell'anno, i sessi, ecc.) Nella classe di dominio dell'applicazione principale. Li carico per nome, perché ovviamente MyApplication.Grapedevo ricevere la riga chiamata "Uva", e asserisco che ognuno di essi è stato trovato. In caso contrario, abbiamo un errore di runtime garantito durante l'avvio, che è il meno maligno di tutti gli errori di runtime.

Il controllo rispetto alla stringa è il più leggibile, ma fa il doppio dovere: viene utilizzato sia come identificativo che come descrizione (che può cambiare per motivi non correlati).

Di solito divido entrambi i compiti in campi separati:

id  code    description
 1  grape   Grapes
 2  apple   Apple

Dove la descrizione può cambiare (ma non "Uva" in "Banana"), ma il codice non può cambiare, mai.

Anche se questo è principalmente dovuto al fatto che i nostri ID sono quasi sempre generati automaticamente, e quindi non sono adatti. Se puoi scegliere liberamente gli ID, forse puoi garantire che siano sempre corretti e utilizzarli.

Inoltre, con quale frequenza qualcuno modifica veramente "Uva" in "Uva"? Forse nulla di tutto ciò è necessario.

Quello che ti aspetti qui è che la logica di programmazione sia automaticamente adattabile alla modifica dei dati. Le semplici opzioni statiche come Enum non funzionano qui perché non è possibile aggiungere enumerazioni extra in fase di esecuzione.

Alcuni schemi che ho visto:

• Enums + default per la protezione da una nuovissima voce di database che rovina la giornata del tuo programma.
• Codifica delle azioni da eseguire (logica biz) nel database stesso. In molti casi questo è molto possibile perché molte logiche vengono riutilizzate. L'implementazione della logica dovrebbe essere nel programma.
• Attributi / colonne extra nel database per contrassegnare il nuovo valore come "da ignorare" nel programma fino a quando il programma non viene distribuito correttamente.
• Meccanismi rapidi non riusciti attorno al percorso del codice che carica / ricarica i valori dal database. (Se l'azione corrispondente non è nel programma E non è contrassegnata per essere ignorata, non eseguire l'aggiornamento).

In generale, mi piace che i dati siano completi in termini di riferimento alle azioni che implica - anche se le azioni stesse potrebbero essere implementate altrove. Qualsiasi codice che determina azioni indipendenti dai dati ha appena diviso la rappresentazione dei dati che molto probabilmente divergerà e porterà a bug.

Memorizzarli in entrambi i posti (in una tabella e in un ENUM) non è poi così male. Il ragionamento è il seguente:

Memorizzandoli in una tabella di database, possiamo imporre l'integrità referenziale nel database tramite chiavi esterne. Pertanto, quando si associa una persona o qualsiasi entità a un frutto, nella tabella del database esiste solo un frutto.

Memorizzarli come ENUM ha senso anche perché possiamo scrivere codice senza stringhe magiche e rende il codice più leggibile. Sì, devono rimanere sincronizzati, ma davvero quanto sarebbe difficile aggiungere una riga all'ENUM e una nuova istruzione insert al database.

Una cosa, una volta definito un ENUM, non cambia il suo valore. Ad esempio, se avessi:

• Mela
• Uva

NON rinominare Uva in Uva. Aggiungi semplicemente un nuovo ENUM.

• Mela
• Uva
• Uva

Se è necessario migrare i dati, applicare un aggiornamento per spostare tutta l'Uva in Uva.

Hai ragione a porre questa domanda, in realtà è una bella domanda mentre stai tentando di difenderti dalla valutazione di condizioni imprecise.

Detto questo, la valutazione (le tue ifcondizioni) non deve necessariamente essere al centro di come aggirarla. Prestare invece attenzione al modo in cui si propagano le modifiche che potrebbero causare un problema "non sincronizzato".

Approccio alla stringa

Se è necessario utilizzare stringhe, perché non esporre la funzionalità di modifica dell'elenco tramite l'interfaccia utente? Progettare il sistema in modo che su di cambiare Grapea Grapes, per esempio, di aggiornare tutti i record attualmente riferimento Grape.

Approccio ID

Preferirei sempre fare riferimento a un ID, nonostante il compromesso di una certa leggibilità. The list may be added topuò di nuovo essere qualcosa di cui verrai avvisato se esponessi tale funzionalità dell'interfaccia utente. Se ti preoccupi del riordino degli elementi che cambiano l'id, propaga nuovamente tale modifica a tutti i record dipendenti. Analogamente a quanto sopra. Un'altra opzione (seguendo la convenzione di normalizzazione corretta, sarebbe quella di avere una colonna enum / id - e fare riferimento a una FruitDetailtabella più dettagliata , che ha una colonna 'Ordine' che puoi cercare).

Ad ogni modo, puoi vedere che sto suggerendo di controllare la modifica o l'aggiornamento del tuo elenco. Se lo fai attraverso l'uso di un ORM o altri accessi ai dati è determinato dalle specifiche della tua tecnologia. In sostanza, ciò che stai facendo è richiedere a queste persone di allontanarsi dal DB per tali cambiamenti, cosa che penso vada bene. La maggior parte dei CRM principali farà lo stesso requisito.

Un problema molto comune Anche se la duplicazione del lato client dei dati sembra violare i principi DRY , è in realtà dovuta alla differenza di paradigma tra i livelli.

Avere l'enum (o qualsiasi altra cosa) al passo con il database non è neanche così raro. È possibile che sia stato inviato un altro valore a una tabella di metadati per supportare una nuova funzionalità di report non ancora utilizzata nel codice lato client.

A volte succede anche nell'altro modo. Un nuovo valore enum viene aggiunto al lato client ma l'aggiornamento del DB non può avvenire fino a quando il DBA non può applicare le modifiche.

Supponendo che stiamo parlando di ciò che è essenzialmente una ricerca statica, la terza opzione - l'enum - è sostanzialmente l'unica scelta sana. È quello che faresti se il database non fosse coinvolto, quindi ha senso.

La domanda diventa quindi quella su come mantenere sincronizzati enum e tabelle statiche / di ricerca nel database e sfortunatamente non è un problema a cui ho ancora una risposta completa.

Per scelta faccio tutto il mio schema di manutenzione nel codice e quindi posso mantenere una relazione tra una build dell'applicazione e una versione dello schema prevista, quindi è semplice mantenere sincronizzati la ricerca e l'enum, ma è qualcosa che bisogna ricordare fare. Sarebbe meglio se fosse più automatizzato (e anche un test di integrazione automatizzato per garantire che gli enumerazioni e le ricerche corrispondessero aiutassero) ma non è qualcosa che io abbia mai implementato.