Где хранить строки, необходимые в. NET Core 3.0 приложении?

Question

Я пишу простой API в. NET Core 3.0. Я хотел бы знать лучший подход для хранения строк, которые нужны моему приложению. В качестве примера у меня есть фрагмент кода:

 var user = await _userService.GetUserByIdAsync(id);

 if (user == null)
     return BadRequest(new { Message = "User does not exist" });

Каждый раз, когда мое приложение должно выполнить какое-либо действие над пользователем, сначала оно проверяет, существует ли пользователь. В противном случае возвращается сообщение «Пользователь не существует». Проблема в том, что код из фрагмента появляется в нескольких методах контроллера (я знаю, я мог бы создать метод и поместить туда код, чтобы избежать повторения, но я думаю, что это не большое улучшение. Может, я ошибаюсь?) , Я не хотел бы иметь жестко закодированный текст в нескольких местах в моем коде, все эти сообщения должны указывать на какой-то ресурс, который должен хранить строки для моего приложения. Я слышал, что некоторые разработчики хранят такие данные в файлах ресурсов. Каковы преимущества этого подхода? Я знаю, что файлы ресурсов также используются для получения надлежащих текстовых сообщений для разных культур, но мое приложение поддерживает только одну культуру. Как создать файл ресурсов (общий, для всех культур), из которого я мог бы читать текст? Это хороший подход или есть лучшие решения?

Answer 1

Вы можете поместить свои строки в файл ресурсов или постоянный файл. Файл ресурсов позволит вам использовать культуры. Поэтому завтра, если вы решите поддерживать несколько культур, вам будет легко с этим справиться. Существуют некоторые готовые возможности, которые обеспечивает ядро. Net: -

В вашем методе ConfigureService.

services.AddLocalization(o => o.ResourcesPath = "Resources");

Метод настройки.

app.UseRequestLocalization(roptions =>
{
    IList<CultureInfo> supportedCultures = new List<CultureInfo>
    {
         new CultureInfo("en-US"),
         new CultureInfo("fr"),
    };

   roptions.DefaultRequestCulture = new RequestCulture("en-US");
   roptions.SupportedCultures = supportedCultures;
   roptions.SupportedUICultures = supportedCultures;

});

Тогда единственное, что вам нужно сделать, это ввести ниже, где бы вы ни хотели использовать.

IStringLocalizerFactory stringLocalizerFactory.

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

Answer 2

Как создать файл ресурса (совместно используемый, для всех культур)

По умолчанию, если вы добавляете новый файл ресурса в свой проект без суффикса (например, Resource1.resx), тогда это будет общий ресурс, означающий, что получение ресурса с помощью CultureInfo.InvariantCulture вернет этот ресурс.

Ресурсы находятся в иерархии, а конечная root является инвариантной культурой. Например, если свойство Thread.CurrentUICulture возвращает культуру en-US, то ResourceManager пытается получить ресурсы American-Engli sh в первую очередь (в нашем примере: ресурсы из Resource1.en-US.resx), если таковые имеются , Если такие ресурсы не были найдены, он пытается использовать нейтральные ресурсы Engli sh (Resource1.en.resx) и, наконец, инвариантные (общие) ресурсы.

Совет: Если ваш Резервные (общие) ресурсы уже есть в Engli sh, тогда вы можете сделать «ярлык», добавив атрибут [assembly:NeutralResourcesLanguage("en-US")] в вашу сборку. Он сообщает ResourceManager, что для культуры en-US не требуется обход иерархии, но он может сразу перейти к инвариантным ресурсам.

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

Ваше приложение сможет поддерживать больше языков без каких-либо изменений кода (даже если вы не устанавливаете Thread.CurrentUICulture, его значение по умолчанию зависит от текущих региональных настроек).

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

Совет 2: Если вы хотите добавить новые языки в свой проект без перекомпиляции исходного кода, тогда вы можете попробовать HybridResourceManager* Класс 1036 *, который может напрямую использовать файлы .resx. Таким образом, даже пользователи уже развернутого приложения могут добавлять новые языки. См. Также класс DynamicResourceManager, который может динамически генерировать новые языковые файлы. Связанная страница содержит также пример того, как организовать ваши ресурсы. ( ссылка nuget )