Memorizzazione dei dati nel codice

Vorrei andare con l'opzione uno. È semplice e amp; facile da leggere. Qualcun altro che osserva il tuo codice lo capirà immediatamente. Sarà anche più semplice aggiornare i tuoi dati XML, se necessario. (In più puoi lasciare che l'utente li aggiorni se hai un bel front-end e memorizzi i file separatamente)

Ottimizzalo solo se necessario - l'ottimizzazione prematura è malvagia:)

Dato che si tratta essenzialmente di coppie chiave-valore, ti consiglio di archiviare queste stringhe come file di risorse incorporato nel tuo assembly in fase di compilazione. Puoi quindi leggerli utilizzando un ResourceManger . Il tuo codice sarà simile a questo:

private static class CountryHelper
{
    private static ResourceManager rm;

    static CountryHelper()
    {
        rm = new ResourceManager("Countries",  typeof(CountryHelper).Assembly);
    }

    public static Country GetByCode(string code)
    {
        string countryName = rm.GetString(code + ".EnglishName");
        return new Country { Code = code, EnglishName = countryName };
    }
}

Per renderlo un po 'più efficiente puoi caricarli tutti in una volta, in questo modo:

private static class CountryHelper
{
    private static Dictionary<string, Country> countries;

    static CountryHelper()
    {
        ResourceManager rm = new ResourceManager("Countries",  typeof(CountryHelper).Assembly);
        string[] codes = rm.GetString("AllCodes").Split("|"); // AU|SE|... 
        countries = countryCodes.ToDictionary(c => c, c => CreateCountry(rm, c));
    }

    public static Country GetByCode(string code)
    {
        return countries[code];
    }

    private static Country CreateCountry(ResourceManager rm, string code)
    {
        string countryName = rm.GetString(code + ".EnglishName");
        return new Country { Code = "SE", EnglishName = countryName };
    }
}

Questo ti aiuterà molto se hai bisogno di far supportare l'applicazione in più lingue.

Se questa sembra essere un'applicazione WPF, un dizionario risorse è una soluzione molto più ovvia.

Il miglior esempio di ciò che esiste è probabilmente WPF ... I tuoi moduli sono scritti in XAML, che è fondamentalmente XML, tranne che .NET è in grado di reidratarlo in una rappresentazione di oggetti molto rapidamente. Il file XAML è compilato in un file BAML e schiacciato nel file ".resources", che viene quindi incorporato nell'assembly (l'ultima versione di reflector .NET può mostrarti questi file).

Sebbene non ci sia una grande documentazione per supportarlo, MSBuild dovrebbe in effetti essere in grado di prendere un file XAML, convertirlo in BAML e incorporarlo per te (lo fa per i moduli giusto?).

Quindi, il mio approccio sarebbe: Archivia i tuoi dati in XAML (è solo una rappresentazione XML di un grafo di oggetti), inserisci XAML in un file di risorse e incorporalo nell'assembly. Al runtime, prendi lo XAML e usa XamlServices per reidratarlo. Quindi, avvolgilo in un membro statico o usa Dependency Injection se vuoi che sia più testabile, per consumarlo dal resto del codice.

Alcuni link che sono materiale di riferimento utile:

• AL.exe (per incorporare le risorse negli assiemi)
• Resgen.exe (per convertire i file .resx in risorse)
• Classe XamlServices

Nota a margine, puoi effettivamente utilizzare i file app.config o web.config per caricare oggetti ragionevolmente complessi attraverso il meccanismo delle impostazioni se vuoi che i dati vengano modificati più facilmente. E puoi anche caricare XAML dal file system.

Suppongo che System.Globalization.CultureInfo.GetCulture (nome) chiami le API di Windows per ottenere i dati da un file di sistema.

Per caricare i dati nel codice, come aveva detto @svick, se stai per caricare 200 oggetti, nella maggior parte dei casi non sarà un problema, a meno che il tuo codice non funzioni su alcuni dispositivi con poca memoria.

Se i tuoi dati non cambiano mai, la mia esperienza sta semplicemente usando un elenco / dizionario come:

private static readonly Dictionary<string, Country> _countries = new Dictionary<string,Country>();

Ma il problema è che devi trovare un modo per inizializzare il tuo dizionario. Immagino che questo sia il punto dolente.

Quindi il problema è cambiato in "Come generare i tuoi dati?". Ma questo riguarda ciò di cui hai bisogno.

Se desideri generare dati per i Paesi, puoi utilizzare

System.Globalization.CultureInfo.GetCultures()

ottieni l'array di CultrueInfo e potresti inizializzare il dizionario con le tue esigenze.

E ovviamente puoi inserire il codice in una classe statica e inizializzare il dizionario nel costruttore statico come:

public static class CountryHelper
{
    private static readonly Dictionary<string, Country> _countries;
    static CountryHelper()
    {
        _countries = new Dictionary<string,Country>();
        // initialization code for your dictionary
        System.Globalization.CultureInfo[] cts = System.Globalization.CultureInfo.GetCultures(System.Globalization.CultureTypes.AllCultures);
        for(int i=0; i < cts.Length; i++)
        {
            _countries.Add(cts[i].Name, new Country(cts[i]));
        }
    }

    public static Country GetCountry(string code)
    {
        Country ct = null;
        if(this._countries.TryGet(code, out ct))
        {
            return ct;
        } else
        {
            Log.WriteDebug("Cannot find country with code '{0}' in the list.", code);
            return null;
        }
    }
}

La decisione è davvero: vuoi che solo lo sviluppatore (o chiunque abbia accesso a un sistema di compilazione) possa modificare i dati quando ha bisogno di essere modificato, o se un utente finale o eventualmente qualcuno nell'organizzazione dell'utente finale può modificare i dati?

In quest'ultimo caso, suggerirei che un file in formato leggibile dall'utente e modificabile dall'utente sarebbe memorizzato in un posto dove l'utente può accedervi. Ovviamente quando leggi i dati devi stare attento; qualunque cosa tu possa trovare, non ci si può fidare che siano dati validi. Probabilmente preferirei JSON a XML; Trovo più facile capire e avere ragione. È possibile verificare se è disponibile un editor per il formato dei dati; per esempio se usi un plist su MacOS X allora ogni utente che dovrebbe mai avvicinarsi ai dati avrà un editor decente sul suo computer.

Nel primo caso, se i dati fanno parte della tua build, non fanno davvero la differenza. Fai ciò che è più conveniente per te. In C ++, scrivere i dati con un sovraccarico minimo è uno dei pochi posti in cui sono consentite le macro. Se il lavoro di gestione dei dati viene eseguito da una terza parte, è possibile inviare loro i file di origine, lasciarli modificare e si è quindi responsabili di controllarli e utilizzarli nel progetto.