Utilizzo di Enum per lo "stato" di un oggetto livello dati in C #

Question

Ho un oggetto dati (diciamo che si chiama 'Entry') che ha una serie di stati potenziali che assomigliano a questo:

1 - Created
2 - File added
3 - Approved
4 - Invalid

Questo è rappresentato nel database con una tabella 'Status' con una chiave primaria autonumber, quindi un campo 'StatusId' nella tabella principale, con le relazioni appropriate impostate.

Nel mio livello (personalizzato) di dati, ho l'oggetto 'Entry' e, attualmente, dichiaro anche un Enum con gli stati sopra elencati. Dichiaro infine un'istanza privata di questo Enum insieme alla proprietà pubblica appropriata.

Nel mio metodo 'Commit ()' ho lanciato l'istanza di Enum su un numero intero e lo ho passato a una procedura memorizzata di aggiornamento.

Nel mio metodo statico 'GetEntry ()' ovviamente avrò un numero intero restituito dal database. Quindi uso il metodo 'Enum.Parse ()' per estrarre un oggetto che è un'istanza del mio Enum che corrisponde all'intero di stato restituito. Lo lancio al tipo del mio Enum e lo assegno alla variabile privata locale.

La mia domanda è piuttosto semplice: è appropriato questo approccio, e se non quale alternativa, oltre a memorizzare il valore intero grezzo (che non sono necessariamente contrario), è meglio.

La mia ragione per chiedere è che tutto ciò mi sembra incredibilmente confuso, con tutto il casting e il mantenimento di due elenchi dello stesso insieme di valori. Accetto che il vantaggio risieda in un'esperienza migliore per il consumatore dell'oggetto dati, ma anche così ...

Grazie!

Answer 1

Abbiamo qualcosa di familiare in uno dei nostri progetti. Abbiamo una tabella che contiene i tipi di articoli. Questi tipi hanno un id, nel codice abbiamo un enum con gli stessi id. Il fatto è che nel database non usiamo autonumber (identità), quindi abbiamo il pieno controllo dell'id. E quando salviamo il nostro oggetto prendiamo semplicemente l'id dell'enum per salvare l'oggetto. Ho anche pensato che questo approccio fosse disordinato ma non è poi così male.

Answer 2

Questo metodo mi sembra perfetto.

In passato ho fatto la stessa cosa ma avevo anche una tabella che conteneva una riga per ogni membro dell'enum che era quindi la chiave esterna per qualsiasi tabella che utilizzava il valore enum, così qualcuno che leggeva il database poteva capire quale fosse ogni stato senza dover vedere l'enum reale.

per esempio se avessi un enum come

enum status
{
    Active,
    Deleted,
    Inactive
}

Avrei una tabella chiamata status che avrebbe i seguenti record

ID & nbsp; & nbsp; Nome
0 & nbsp; & nbsp; & nbsp;
attivo 1 & nbsp; & nbsp; & nbsp;
eliminata 2 & nbsp; & nbsp; & nbsp; Inattivo

Quella tabella sarebbe quindi la chiave esterna per qualsiasi tabella che ha usato quell'enum.

Answer 3

Sì, va bene!

PER FAVORE, imposta sempre esplicitamente i valori in questo modo. In questo modo, se qualcuno dovesse mai aggiungere qualcosa, si renderanno conto che i valori sono importanti e non dovrebbero essere confusi.

enum status
{
    Active = 1,
    Deleted = 2,
    Inactive = 3
}

Se si passa il valore tramite WCF, consigliamo di aggiungere

  NULL = 0

Altrimenti se provi a serializzare uno 0 proveniente dal database otterrai un errore orribile e ti ci vorrà un'eternità per eseguire il debug.

Answer 4

è necessaria la tabella di ricerca del database; l'enumerazione programmatica è conveniente per evitare di avere "numeri magici" nel codice

se il tuo codice non ha bisogno di manipolare lo stato, tuttavia, l'enum non è necessario

Answer 5

Faccio sempre questo approccio con Enums. Se si tratta di un oggetto semplice come lo stato che non dovrebbe mai cambiare, preferisco l'Enum. L'analisi e il casting sono un'operazione a impatto molto basso.

Lo sto facendo con successo con Linq to Sql da qualche tempo senza problemi. Linq convertirà effettivamente da Enum a int e viceversa automaticamente.

Il codice va oltre la velocità ma la leggibilità. Gli enum rendono il codice leggibile.

Per rispondere direttamente alla tua domanda questo è un apporach molto valido.

Answer 6

Se il tuo codice richiede un'impostazione nota " Stato " valori (che hai definito nella tua enum), quindi probabilmente è anche un requisito che questi "Status" i valori esistono nel database. Dal momento che devono esistere, dovresti avere anche il controllo sullo Status_ID assegnato a ciascuno di questi valori.

Rilascia l'identità e imposta esplicitamente gli ID del valore di ricerca.