Modo pratico per memorizzare una quantità "ragionevolmente grande" di dati che non cambia quasi mai?

Il mio suggerimento è di mantenere i dati in una tabella di file o database. Se la velocità non è un problema, interrogare il file o il database (il database è migliore) in fase di esecuzione. Se la memoria non è un problema, ma desideri una certa velocità, carica i dati in memoria all'avvio del programma. In C # è possibile utilizzare e array, elenco o (opzione migliore) una tabella hash e disporre di un metodo per restituire i dati necessari al runtime (ad es. GetDataValue (stringa keyToValue)).

Raccomando di non utilizzare l'istruzione switch in quanto sarebbe molto difficile da mantenere e comporterebbe un ingente spazio di lavoro.

Tabella hash, ad esempio link

Personalmente, sono sicuro di memorizzare qualsiasi quantità di dati, codificata nell'applicazione, finché non è necessario modificarla per una specifica distribuzione o hotfix.

Tuttavia, la memorizzazione e l'accesso ai dati mediante l'istruzione switch C #, è una pratica piuttosto negativa, dal momento che unisce strettamente l'archiviazione dei dati e il modello di accesso ai dati e implica solo un metodo di accesso al metodo (parametro switch).

Preferirei memorizzare i dati in un Hashtable o in un dizionario e fornire classi separate per il recupero dei dati e una volta il popolamento dei dizionari di ricerca.

Recentemente, ho trovato piuttosto conveniente implementare il piccolo DSL per specificare le regole di business ( interfaccia fluente per SiteMap o domanda intervista sul calcolatore delle imposte verifica il metodo" calc "per la defenizione delle regole) e poi fornisci oggetto separato per interrogare queste regole. Questa tecnica si applicherebbe bene per lo scenario caso di commutazione.

Uno dei vantaggi di questa decomposizione è che puoi implementare un numero di viste sui tuoi dati, senza toccare XXXk lines blob, che definisce tali dati.

Una dichiarazione dell'interruttore di linea a 40k è un po 'discutibile. Suppongo tu abbia ancora bisogno di eseguire operazioni di query, giusto? Hai provato a incapsulare i dati? Quindi utilizzare LINQ per eseguire operazioni di query sulla raccolta per testare le prestazioni. Ottieni alcuni momenti concreti eseguendo i test unitari con un timer come StopWatch . Quindi, se pensi che potrebbe funzionare. Verifica se le prestazioni sono accettabili per gli utenti.

Ho avuto un requisito come questo due volte. Le applicazioni sono state progettate per essere indipendenti senza necessità di configurazione / accesso al database. In entrambi i casi ho usato file XML per archiviare i dati. Nella prima, che era su 2.0 Framework, ho usato le chiamate di parsing XML di vecchio stile per cercare i dati. Per il più recente, sul 3.5 Framework, ho usato LINQ in XML per trovare ciò di cui avevo bisogno. In entrambi i casi, l'accesso ai dati è stato incapsulato in classi.

La cosa fondamentale qui è assicurarsi che la tua interfaccia pubblica incapsuli la tua implementazione, ma questa non è la tua domanda e non c'è motivo di pensare che tu non abbia. Oltre a ciò, è solo una questione di prestazioni vs dolore (e le differenze di prestazioni potrebbero non valere la pena di preoccuparsi). Come soluzione pratica, per il problema di VS 2010, è sempre possibile suddividere la dichiarazione del caso in una gerarchia di istruzioni caso - il livello più alto potrebbe chiamare uno degli altri 10 metodi, ciascuno con una dichiarazione caso di 4000 casi, ad esempio. Potresti inserire ognuno dei 10 nel proprio file, se necessario. Un po 'brutto, ma comunque stai generando codice.

Per quanto riguarda il numero da passare a un DB -è solo quando non si utilizza un DB diventa un problema.

Potresti usare qualcosa come SQL Compact. Metti i dati in una tabella e lascia il file DB nel progetto. Le tabelle sono più adatte a quella quantità di dati rispetto a un'istruzione switch.

Penso che la parola chiave qui sia "difficilmente"

Se i dati mai cambiano - ad esempio, valori matematici pre-calcolati, costanti di colore e simili - allora certo, finché la dimensione è gestibile per te, tienilo nel codice . Tieni presente che se le prestazioni sono un problema, le istruzioni caso / switch saranno molto lente rispetto ad altre opzioni.

Se i dati difficilmente cambiano mai, ad esempio i prefissi telefonici, i confini nazionali e simili, probabilmente guarderei i dati esternamente in qualche modo. Soprattutto se ha iniziato ad arrivare a più di una dozzina di valori.

Se si archiviano grandi volumi di dati nell'applicazione, il programma potrebbe caricarsi più lentamente e si potrebbe esporre il codice a rischi nel caso in cui qualcuno potrebbe giocare con i file binari o eseguibili.

Inoltre, se il programma viene modificato molte volte, chissà, potrebbe essere possibile introdurre errori digitando erroneamente un numero per errore o come risultato del comando di modifica.

In futuro qualcuno potrebbe chiedere di eseguire query sui dati, ad esempio qualcuno potrebbe chiedere la media di una colonna, nel qual caso dovrai cambiare la tua applicazione e aggiungere un metodo per calcolare ogni query tua l'utente si avvicina, quindi segui tutti i passaggi per promuovere il tuo codice in produzione. Questo non è davvero buono.

Separare dati e codice è una buona pratica specialmente se i dati sono grandi.