Almacenando datos en código

Iría con la opción uno. Es simple y amp; fácil de leer. Alguien más mirando su código lo entenderá de inmediato. También será más fácil actualizar sus datos XML si es necesario. (Además, podría dejar que el usuario los actualice si tiene un buen interfaz y almacenó los archivos por separado)

Solo optimícelo si lo necesita; la optimización prematura es mala :)

Dado que estos son esencialmente pares clave-valor, recomiendo almacenar estas cadenas como un archivo de recursos incrustado en su montaje en tiempo de compilación. Luego puede leerlos utilizando un ResourceManger . Su código se vería así:

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 };
    }
}

Para hacerlo un poco más eficiente, puedes cargarlos todos a la vez, de esta manera:

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 };
    }
}

Esto te ayudará a mucho si alguna vez necesitas que tu aplicación sea compatible con varios idiomas.

Si se trata de una aplicación WPF, un diccionario de recursos es una solución mucho más obvia.

El mejor ejemplo de esto que existe es probablemente WPF ... Sus formularios están escritos en XAML, que es básicamente XML, excepto que .NET puede rehidratarlos en una representación de objetos muy rápidamente. El archivo XAML se compila en un archivo BAML y se comprime en el archivo ".resources", que luego se incrusta dentro del ensamblaje (la última versión del reflector .NET puede mostrarle estos archivos).

Aunque no hay una gran documentación que lo respalde, MSBuild debería, de hecho, poder tomar un archivo XAML, convertirlo en BAML e insertarlo (¿lo hace para los formularios, no?).

Por lo tanto, mi enfoque sería: Almacene sus datos en XAML (es solo una representación XML de un gráfico de objetos), las cosas que XAML en un archivo de recursos, e incruste en el ensamblaje. En el tiempo de ejecución, tome XAML y use XamlServices para rehidratarla. Luego envuélvalo en un miembro estático o use Inyección de dependencia si desea que sea más comprobable, para consumirlo del resto de su código.

Algunos enlaces que son material de referencia útil:

• AL.exe (para incrustar recursos en ensamblajes)
• Resgen.exe (para convertir archivos .resx a recursos)
• clase XamlServices

En una nota al margen, puedes usar los archivos app.config o web.config para cargar objetos razonablemente complejos a través del mecanismo de configuración si quieres que los datos se cambien más fácilmente. Y también puedes cargar XAML desde el sistema de archivos.

Supongo que System.Globalization.CultureInfo.GetCulture (nombre) llamaría a las API de Windows para obtener los datos de un archivo del sistema.

Para cargar los datos en código, como dijo @svick, si está a punto de cargar 200 objetos, no será un problema en la mayoría de los casos, a menos que su código se ejecute en algunos dispositivos con poca memoria.

Si sus datos nunca cambian, mi experiencia es simplemente usando una lista / diccionario como:

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

Pero el problema es que necesita encontrar una manera de inicializar su diccionario. Supongo que este es el punto de dolor.

Por lo tanto, el problema se cambia a "¿Cómo generar sus datos?". Pero esto se relaciona con lo que necesitas.

Si desea generar datos para los países, puede utilizar el

System.Globalization.CultureInfo.GetCultures()

obtenga la matriz CultrueInfo, y podría inicializar su diccionario con sus necesidades.

Y, por supuesto, podría colocar el código en una clase estática e inicializar el diccionario en el constructor estático como:

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 decisión es realmente: ¿Desea que solo el desarrollador (o cualquier persona con acceso a un sistema de compilación) modifique los datos cuando sea necesario modificarlos, o debe un usuario final o posiblemente alguien de la organización del usuario final? ¿Para modificar los datos?

En el último caso, sugeriría que un archivo en formato legible por el usuario y editable por el usuario se almacene en un lugar donde el usuario pueda acceder a él. Obviamente, cuando lees los datos necesitas tener cuidado; Todo lo que encuentre no puede ser confiable como datos válidos. Probablemente prefiero JSON a XML; Me resulta más fácil de entender y hacer las cosas bien. Puede verificar si hay un editor disponible para el formato de datos; por ejemplo, si utiliza un plist en MacOS X, cada usuario que deba acercarse a los datos tendrá un editor decente en su computadora.

En el primer caso, si los datos son parte de su compilación, realmente no hay una diferencia. Haz lo que sea más conveniente para ti. En C ++, escribir los datos con una sobrecarga mínima es uno de los pocos lugares donde se permiten macros. Si un tercero realiza el trabajo de mantenimiento de los datos, puede enviarles los archivos de origen, permitirles editarlos y, a continuación, es responsable de verificarlos y utilizarlos en su proyecto.