C'è qualche danno nell'avere molti valori enum? (molti> = 1000)

Question

Ho una lunga lista di messaggi di errore che il mio codice biz può restituire in base a ciò che viene inserito. L'elenco potrebbe finire con più di mille.

Mi piacerebbe solo enumarli tutti, usando l'attributo [Description ("")] per registrare il messaggio amichevole.

Qualcosa di simile:

public enum ErrorMessage 
{ 
    [Description("A first name is required for users.")] 
    User_FirstName_Required = 1, 
    [Description("The first name is too long. It cannot exceed 32 characters.")] 
    User_FirstName_Length = 2, 
    ... 
} 

so enumerazioni sono tipi primitivi, numeri interi in particolare. Non dovrebbero esserci problemi con quel numero di interi, giusto?

C'è qualcosa a cui non sto pensando? Sembra che questo dovrebbe essere a posto, ma ho pensato che avrei dovuto chiedere alla comunità prima di passare il tempo a farlo in questo modo.

.Net si preoccupa dei tipi di enumerazione quando hanno molti valori?

Aggiornamento

Il motivo non ho voluto utilizzare le risorse è perché

a) ho bisogno di essere in grado di fare riferimento a ogni messaggio di errore unico, con un valore intero. Il livello biz fornisce un'API, oltre ad altre cose, e deve essere restituito un elenco di valori interi che denotano gli errori. Non credo che le risorse ti consentano di indirizzare un valore di risorsa con un numero intero. Ho sbagliato?

b) Non ci sono requisiti di localizzazione.

Answer 1

1000 non è molti, si deve solo fare in modo che il tipo integer sottostante è abbastanza grande (non utilizzare un char per la vostra enum.

Ripensandoci 1000 è tonnellate, se li stai inserendo manualmente , se sono generati da un set di dati, potrebbe avere un senso ...

Answer 2

Penso che un design che ha più di 1.000 valori in un enume ha bisogno di un po 'di riflessione. Sembra che un anti-pattern "God Enum" avrà da inventare per questo caso

Answer 3

L'inconveniente principale che vorrei sottolineare con l'amichevole de la descrizione in un attributo è che ciò causerà delle sfide se hai bisogno di localizzare la tua app per un'altra lingua. Se questa è una considerazione, sarebbe una buona idea mettere le stringhe in un file di risorse.

L'enum in sé non dovrebbe essere un problema, anche se avere tutti i codici di errore in un elenco principale può essere fonte di confusione. Potresti considerare la creazione di enumerazioni separate per categorie separate di codici di ritorno, in quanto ciò renderà più facile per gli sviluppatori comprendere i possibili valori di ritorno per una particolare funzione. Puoi comunque assegnare loro valori numerici distinti (specificando esplicitamente i valori numerici) se è importante che i codici siano univoci.

Nota a margine, .NET BCL non utilizza molto i codici di ritorno e i codici di ritorno sono in qualche modo scoraggiati nel moderno sviluppo .NET. Creano problemi di manutenibilità (non puoi quasi mai rimuovere vecchi codici di ritorno o rischiare di rompere la compatibilità con le versioni precedenti) e richiedono una logica di convalida speciale per gestire i ritorni per ogni chiamata. La convalida stateful può essere eseguita con IDataErrorInfo, in cui si utilizza una classe intermedia che può rappresentare stati non validi, ma che consente solo un commit delle modifiche che vengono convalidate. Questo ti permette di manipolare liberamente l'oggetto, ma anche di fornire un feedback all'utente sulla validità del suo stato.La logica equivalente con i codici di errore spesso richiede un'istruzione switch per ogni utilizzo.

Answer 4

Concordo pienamente con duffymo. Un enum con più di 1000 valori ha un cattivo odore dal punto di vista del design. Per non parlare del fatto che sarebbe molto spiacevole per lo sviluppatore usare l'intelligenza su un GOD ENUM :-) Farei meglio ad usare le risorse.

Answer 5

Penso che sia molto brutto, per la gestione degli errori si può semplicemente utilizzare la risorsa, come vedo che si desidera fare riflessioni e recuperare la descrizione è anche male. Se non si desidera utilizzare le risorse, è possibile definire diverse enum per ciascuna delle regole aziendali, inoltre la propria attività non ha bisogno di altri messaggi di errore (e non dovrebbe essere così).