字符串资源文件命名方案和管理

Question

也许是一个微不足道的问题，但我对答案很感兴趣。我目前正在重构一些非常大的单片字符串资源文件（每个项目一个dumpster资源文件，在大约30个项目中）。我正在拆分它们，以便我们遵循文件的约定，并使编码时更容易查找和管理字符串。

通常我将文件分成这个方案：

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

我对这个命名并不十分兴奋，我只是想知道其他人使用什么。例如，我没有看到AppResources（应用程序内部使用的字符串），而是看到很多演示项目使用StringResources，Internal（太糟糕了！）等等。

有关管理资源或标准命名方案的想法/轶事/建议表示赞赏。

Answer 1

我通常会像这样构建我的资源：

第一个资源文件由整个应用程序使用（例如Project.Core），并且包含各种广泛使用的公共字符串。我实际上在错误/异常和日志记录之间没有任何区别：

• 的 CommonResources.resx
  访问修饰符：公共
  • 的 Error_Context
    例如Error_ArgumentCannotBeNull
  • 的 Warn_Context
    例如Warn_ApplicationSettingNotFoundUseDefault
  • 的 Info_Context
    例如Info_UpdateAvailable
  • 的 Validation_Context
    例如Validation_EmailNotValid

第二个资源文件由表示层使用，包含各种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