13

ささいな質問かもしれませんが、私は答えに興味があります。私は現在、いくつかの非常に大きなモノリシック文字列リソースファイルをリファクタリングしています（プロジェクトごとに1つのダンプスターリソースファイル、約30のプロジェクト）。ファイルの規則に従い、コーディング時に文字列を見つけて管理しやすくするように分割しています。

通常、私はファイルを次のスキームに分割しています。

  • ErrorMessages.resx
  • LogMessages.resx
  • ViewResources.resx
  • AppResources.resx

ネーミングにそれほどワクワクすることはなく、他の人が何を使っているのか気になっているだけです。たとえば、（アプリケーションによる内部使用のための文字列）の代わりに、（ひどい！）などAppResourcesを使用するデモプロジェクトをたくさん見ました。StringResourcesInternal

リソースまたは標準の命名スキームの管理に関するアイデア/逸話/提案をいただければ幸いです。

4

1 に答える 1

16

私は通常、リソースを次のように構成します。

最初のリソースファイルは、アプリケーション全体（たとえばProject.Core）で使用され、広く使用されているあらゆる種類の一般的な文字列が含まれています。私は実際にはエラー/例外とロギングの間に違いはありません：

  • CommonResources.resx
    アクセス修飾子：パブリック
    • Error_Context
      例えばError_ArgumentCannotBeNull
    • Warn_Context
      例えばWarn_ApplicationSettingNotFoundUseDefault
    • Info_Context
      例えばInfo_UpdateAvailable
    • Validation_Context
      例えばValidation_EmailNotValid

2番目のリソースファイルはプレゼンテーション層によって使用され、あらゆる種類のUI文字列が含まれています。名前はプロジェクトごとに異なりますが、通常は次のスキーマのようになります。

  • PresentationResources.resx
    アクセス修飾子：内部
    • Common_Context
      例えばCommon_Yes
    • Section/Controller_Window/View_Context
      例Help_FAQ_HeadlineHowToUseResourcesまたはHelp_FAQ_TextHowToUseResources

最後に、すべてのプロジェクト/アセンブリには、エラー/警告/情報/検証リソース用の内部リソースファイルもあります。これらのリソースは、CommonResources.resxファイルに入れるにはあまりにも具体的です。私は主にこのリソースファイルに名前を付けていることを認めなければなりませんInternalResources.cs;）

  • InternalResources.resx
    アクセス修飾子：内部
    • Classname_Error_Context
      例えばBCrypt_Error_InvalidSaltRevision
    • Classname_Warn_Context
    • Classname_Info_Context
    • Classname_Validation_Context
于 2011-02-10T15:12:31.863 に答える