Есть ли какие-либо проблемы производительности или протесты с ресурсом (.resx) файлы?

Для точки № 4.
Я использовал файлы .resx для всех строк на нашем сайте, которые должны быть локализованы на многие языки, и с ними не возникало каких-либо серьезных проблем.

Единственное, о чем вам нужно подумать, это то, хотите ли вы, чтобы этот текст был быть доступным для поиска. Для некоторых сайтов, над которыми я работаю, есть некоторые локализованные ресурсы, которые должны быть доступны для поиска, поэтому я должен хранить их в базе данных. Однако, когда у меня есть выбор, я предпочитаю файл .resx по причинам, упомянутым выше.

Вот мой взгляд на файлы ресурсов:

1. Я бы предположил, что если есть БОЛЬШОЕ количество строк, то использование базы данных может быть лучшим методом для поиска и сортировки данные. Вероятно, не будет слишком сложно учесть несколько языков в таблице ресурсов, и скорость должна быть максимальной.

2. Я думаю, что это хороший метод для хранения статических ресурсов или вещей, которые могут быть изменены клиентом. . Что касается динамических ресурсов, может быть лучше использовать базу данных отдельно или вместе с файловой системой. Я думаю, что в новом SQL Server есть новый тип, который является оптимальным гибридом использования базы данных и файловой системы.

3. Я читал в другом вопросе (не знаю какой), что использование файлов ресурсов во внешнем проекте является хорошая практика, потому что вы бы не При изменении ресурсов не нужно перекомпилировать весь проект. Просто перекомпилируйте ресурсный проект. Это также позволит (довольно) легко вносить изменения для клиентов, где им потребуется только «исходный код» для проекта ресурса, а не ваш другой реальный код (код API и т. Д.).

4. У меня есть недостаточно используемых файлов ресурсов, чтобы заявлять об их надежности, расширяемости или любых потенциальных проблемах, которые могут возникнуть при работе с ними.

Я просто добавлю, что вам следует искать пользовательские реализации (или принадлежащие вам) поставщика ресурсов (модель поставщика, такая как поставщик членства) для хранения ваших ресурсов в базе данных. Это то, что мы сделали для нашей CMS, и это очень полезно.

Когда мы впервые посмотрели пример, то обнаружили Создание управляемого данными поставщика ресурсов локализации и редактора ASP.NET .

У меня было два проблемы с файлами ресурсов, как из-за производительности переводчиков (людей), сколько из-за скорости поиска строк.

Торговый персонал в надзорном офисе что сделали переводчики не могли справиться с редактированием XML или изучением любого новый инструмент.

Итак, они просто использовали Excel для редактирования переводов. Следовательно, мы могли бы также сохранить переведенные строки как файл CVS, чтобы избежать необходимости копировать переведенные строки в файлы ресурсов.

Необходимо выполнить новую сборку, чтобы требуется эффект от любых переводов.

Еще раз, если бы переведенные строки хранились в виде файла CSV, мы могли бы кэшировать их в кэше ASP.NET. Тогда любые изменения в переводах будут отображаться при следующей загрузке страницы.

Таким образом, мы могли бы использовать настраиваемую реализацию поставщика ресурсов и придерживаться стандартной системы поиска ресурсов ASP.NET. Или просто игнорируйте стандартную систему поиска ресурсов, если она не помогает в вашем случае - это зависит от того, как написаны ваши страницы.

В какой-то момент вы можете обнаружить, что хотите иметь возможность переопределить строки для одиночного customer , в таком случае вам понадобится многоступенчатая система поиска. В противном случае вам придется объединять пользовательские строки с переведенной строкой каждый раз, когда вы отправляете новую версию системы.

Мы использовали файлы ресурсов в относительно большом приложении .NET Windows Forms (более 500 различных форм, примерно 20 строк ресурсов на форму), и у нас не было проблем с производительностью в отношении ресурсов из. resx файлы. Мы использовали Babylon.NET как инструмент для управления переводами (есть бесплатная версия только для переводчиков). Вы не указали, будет ли ваш проект веб-приложением или настольным приложением. Одной из функций, которые файлы ресурсов предлагают для настольных приложений, является возможность также локализовать позиции и размер элементов управления, что, по-моему, невозможно с помощью других инструментов (если вы не используете что-то вроде элемента управления макетом DevExpress с автоматическим изменением размера).