ASP.NET: ¿almacenar mejor el texto de interfaz de usuario localizable en los recursos o en la base de datos?

Question

Parece haber dos enfoques diferentes. El marco de ASP.NET nos brinda una manera fácil de localizar páginas al poner cadenas de interfaz de usuario en recursos, como UserProfile.en.resx, UserProfile.fr.resx etc.

El otro enfoque es poner todas las cadenas en tablas separadas en el la base de datos luego usa algunos mecanismos personalizados para recuperarlos de acuerdo con las configuraciones de idioma/cultura actualmente activas.

Por mucho que lo entiendo, el enfoque de la base de datos es más típico para grandes proyectos, como el software empresarial. También tiene la ventaja de que puede otorgar acceso externo a esa base de datos a una empresa de traducción. Con recursos sería difícil.

Por otro lado, la recuperación de todas las cadenas estáticas de la base de datos es una sobrecarga adicional de tráfico y carga. No puedo ver ningún beneficio para un sitio web relativamente pequeño para hacer eso. "Pequeño" no significa tráfico, sino la cantidad y complejidad de las páginas.

Personalmente prefiero usar recursos para mis proyectos privados. ¿Es esta una idea absolutamente mala?

Por cierto, ¿puedo seguir usando recursos con ASP.NET MVC?

Cualquier pensamiento es apreciado.

EDIT: Una sola respuesta, no puedo creer que esta pregunta no interese a nadie. Nadie quiere compartir sus opiniones?

Answer 1

prefiero guardar toda esta información en una base de datos en lugar de depender de los archivos de recursos asp.net.

Lo que he hecho es subclasificar mis controles comunes (como la etiqueta) y anular el método de renderizado. este método busca la cultura actual y establece la leyenda adecuada al buscar en mis estructuras de datos

con respecto al rendimiento cuando las guardas en una base de datos, esto es lo que hago: en mi evento application_start, simplemente cargo toda mi cultura descripción específica en un objeto personalizado y el caché realmente largo. de esta manera no tengo que acceder a la base de datos hasta que caduque mi caché o la obligue a caducar

hasta ahora nunca hemos tenido ningún problema con el rendimiento siguiendo este enfoque. una vez dicho todo esto - Tenga en cuenta que no estoy diciendo que el uso de archivos de recursos es una mala opción ya sea

pero si se le da una opción para mí, yo preferiría el enfoque de base de datos en lugar del enfoque de archivo de recursos

Answer 2

combinar los dos . Puede escribir un proveedor de recursos personalizado que utiliza una base de datos en lugar de un archivo de recursos para que no tenga que hacer el trabajo pesado de vincular el texto usted mismo (es decir, admitámoslo, propenso a errores), simplemente use ASP. La funcionalidad de localización de NET. MSDN tiene un buen walkthrough por Michelle Leroux Bustamante