Come gestire gli interi di stato dal database nel codice orientato agli oggetti?

Question

Come gestire gli interi di stato dal database nel codice orientato agli oggetti?

#1 da (5 voti)
#2 da (3 voti)

5

Considera una tabella di database di articoli con un flag di stato rappresentato da un numero intero. Alcuni stati potrebbero essere:

0 - Past Storage;
1 - Current Inventory;
5 - Scrap;
6 - Rework;
15 - Processing;

Ora, vorrei evitare di passare e interrogare per "numeri magici" nel mio codice, e in passato ho usato un dizionario per realizzare questo, ma questo approccio sembra meno elegante di quello che spero di ottenere.

In che modo questi tipi di flag di stato vengono recuperati da un database gestito in codice orientato agli oggetti? È con enum, e se sì, come? O è meglio creare una tabella separata con il flag di stato come chiave primaria?

c# object-oriented-design

posta field_b 03.01.2014 - 20:38

fonte

2 risposte

3

Di solito gli interi possono essere rappresentati da enumerazioni nel codice, in quanto ciò renderà più leggibile per i blocchi di codice che usano l'intero.

Esempio:

        public enum StatusFlag
        {
            PastStorage = 0,
            CurrentInventory = 1,
            Scrap = 5,
            Rework = 6,
            Processing = 15,
            Unknown = 99 //Optional
        }

Ho incluso uno sconosciuto opzionale, ma potresti non averne bisogno. Inoltre, questo non è realmente necessario, puoi usare interi come in una cosa del genere:

if (statusflag == 15) //processing

Ma questo introduce alcuni numeri magici come scenari.

Sebbene non sia obbligatorio, dovrebbe esserci una tabella nel database che abbia il numero intero come PK e probabilmente un campo descrizione.

Qualsiasi tabella di riferimento dovrebbe avere FK nella tabella di ricerca dei flag di stato. In questo modo, non è possibile inserire un flag di stato che non è nella tabella.

Se questo non è presente, è possibile inserire qualsiasi numero intero, quindi l'integrità referenziale è inferiore ai dati. Lo svantaggio di questo è che ogni nuovo intero dovrà essere aggiunto al DB e al codice. Se lo si lascia come INT senza relazioni PK / FK, è possibile aggiungere interi ad hoc. Potrebbe essere necessario apportare modifiche al codice se si desidera incorporare la nuova INT con la logica più recente.

Tendo a difendere lo stile enum / PK-FK in quanto le aggiunte dovrebbero essere relativamente semplici. Ciò garantisce anche l'integrità dei dati, che è una buona cosa.

risposta data 03.01.2014 - 21:12

fonte

Leggi altre domande sui tag c# object-oriented-design

Perché l'uso di JavaScript negli attributi HREF è scoraggiato? Va bene per i servizi fare riferimento l'un l'altro?

score 5 · Accepted Answer

Dove lavoro questa è una situazione comune. Quello che facciamo qui è usare le enumerazioni E una tabella separata con il flag di stato come chiave primaria. Nella nostra esperienza, le cose sono state molto più semplici quando la chiave primaria non era un campo di identità. La cosa buona di farlo in questo modo è che il compilatore c # ha un elenco di valori validi (l'enum) e gli amministratori di database e chiunque altro deve lavorare con i dati (scrittori di report) ha anche un elenco di valori validi (la tabella) . Lo svantaggio, ovviamente, è che qualsiasi aggiunta o modifica deve essere fatta in entrambi i posti.