visual valido studio resource recursos read net leer how files archivo agregar c# asp.net resources resx resource-files

c# - valido - ¿Hay problemas de rendimiento o advertencias con los archivos de recursos(.resx)?



resourcemanager c# (7)

1. ¿Hay una mejor solución si hay una gran cantidad de recursos? Al igual que 100.000 cadenas en un archivo .resx? (En teoría, en realidad no tengo este problema)

He utilizado Alfresco como repositorio de contenido alternativo en proyectos de Java. Los archivos RESX, desde el punto de vista del mantenimiento (debido a los problemas de codificación, supongo) realmente pueden apestar.

2. ¿Es este un buen método para almacenar otros tipos de datos, como imágenes, iconos, archivos de audio, archivos regulares, etc.?

Lo he visto funcionar con imágenes ... pero eso es todo. (no estoy seguro con otros medios / archivos)

3. ¿Es una mejor práctica almacenar sus archivos .resx en un proyecto independiente para facilitar la compilación / actualización?

No, pero puedes editar un archivo resx en un sitio en vivo y luego editar, creo. Ciertamente, esa es la forma en que funciona en el desarrollo (a excepción del resx global, creo)

4. ¿Hay algún otro problema que haya tenido al usar archivos .resx?

Además de ser realmente molesto de mantener, y el hecho de que Visual Studio no proporciona las mejores herramientas para trabajar con ellos ... no.

Los archivos de recursos parecen excelentes para la localización de etiquetas y mensajes, pero ¿son perfectos?

Por ejemplo:

  1. ¿Hay una mejor solución si hay una gran cantidad de recursos? Al igual que 100.000 cadenas en un archivo .resx? (En teoría, en realidad no tengo este problema)
  2. ¿Es este un buen método para almacenar los otros tipos de datos, como imágenes, íconos, archivos de audio, archivos regulares, etc.?
  3. ¿Es una mejor práctica almacenar sus archivos .resx en un proyecto independiente para actualizaciones / compilación más fáciles?
  4. ¿Hay algún otro problema que haya tenido al usar archivos .resx?

Aquí está mi opinión sobre los archivos de recursos:

  1. Supongo que si hay una gran cantidad de cadenas, el uso de una base de datos podría ser el mejor método para permitir la búsqueda y clasificación de los datos. Probablemente no sea muy difícil dar cuenta de varios idiomas en una tabla de recursos, y la velocidad debería ser más rápida.

  2. Creo que este es un buen método para almacenar recursos estáticos o cosas que un cliente puede cambiar. En cuanto a los recursos dinámicos, podría ser mejor utilizar una base de datos, ya sea solo o en conjunto con el sistema de archivos. Creo que en el nuevo SQL Server hay un nuevo tipo que es un híbrido óptimo entre el uso de una base de datos y el sistema de archivos.

  3. Leí en otra pregunta (no sé cuál) que el uso de archivos de recursos en un proyecto externo es una buena práctica, porque no tendría que volver a compilar un proyecto completo cuando cambian los recursos. Simplemente recompile el proyecto de recursos. Esto también permitiría realizar ediciones (bastante) sencillas por parte de los clientes, donde solo necesitarían "código fuente" para el proyecto de recursos, y no el otro código real (código API, etc.).

  4. No he utilizado los archivos de recursos lo suficiente como para hacer afirmaciones sobre su confiabilidad, extensibilidad o cualquier posible problema que pueda tener al trabajar con ellos.

He tenido dos problemas con los archivos de recursos, tanto sobre el rendimiento de los traductores (personas), en lugar de la velocidad de búsqueda de cadenas.

El personal de ventas en la oficina de supervisión que tenían los traductores no pudo lidiar con la edición de XML o el aprendizaje de ninguna herramienta nueva.

Entonces solo usaron Excel para editar las traducciones. Por lo tanto, también podríamos haber almacenado las cadenas traducidas como un archivo CVS, evitando así tener que copiar las cadenas traducidas en los archivos de recursos.

Se necesita hacer una nueva compilación para poder necesitar el efecto de cualquier traducción.

Una vez más, si las cadenas traducidas se almacenan como un archivo CSV, podríamos haberlas almacenado en la memoria caché de ASP.NET. Luego, cualquier cambio en las traducciones aparecería en la carga de la página siguiente.

Así que podríamos haber utilizado una implementación personalizada del proveedor de recursos y mantener el sistema de búsqueda de recursos ASP.NET estándar. O simplemente ignore el sistema de búsqueda de recursos estándar si no lo ayuda en su caso, depende de cómo se escriban sus páginas.

Es posible que en algún momento desee anular cadenas para un solo cliente , de ser así, necesitará un sistema de búsqueda de etapas múltiples. De lo contrario, debe fusionar las cadenas personalizadas del cliente con la cadena traducida cada vez que envíe una nueva versión del sistema.

Hemos estado utilizando archivos de recursos en una aplicación relativamente grande .NET Windows Forms (más de 500 formas diferentes, aproximadamente 20 cadenas de recursos por formulario) y no hemos tenido problemas de rendimiento con respecto a los recursos de archivos .resx. Hemos utilizado Babylon.NET como una herramienta para gestionar traducciones (tiene una versión gratuita solo para traductores). No especificó si su proyecto será una aplicación web o de escritorio. Una funcionalidad que los archivos de recursos ofrecen para aplicaciones de escritorio es la capacidad de localizar posiciones de control y tamaño que en mi humilde opinión no es posible usando otras herramientas (a menos que esté usando algo como el control de diseño DevExpress que tiene un tamaño automático).

Para el punto # 4.
He estado utilizando archivos .resx para todas las cadenas de nuestro sitio que deben estar traducidos a varios idiomas y no han tenido problemas importantes con ellos.

Lo único que necesita pensar es si desea que este texto se pueda buscar. Para algunos de los sitios en los que trabajo hay algunos recursos localizados que necesitan ser buscados, así que debo mantenerlos en la base de datos. Sin embargo, cuando tengo la opción, prefiero el archivo .resx por razones similares mencionadas anteriormente.

Recientemente utilicé un archivo .resx con 5 millones de cadenas (longitud normal, como esta oración), compilado en diferentes DLLS de aproximadamente 1 GB de tamaño. Todavía funciona bien en un proyecto web de Azure.

El tiempo de carga es desconocido, tal vez unos segundos más o menos, ya que siempre se puede calentar en etapas, nunca lo noté.