字符串资源文件命名计划和管理

Question

也许是一个琐碎的问题，但我对答案感兴趣。我目前正在重构一些非常大的单片字符串资源文件（每个项目中一个垃圾箱资源文件，大约30个项目）。我将它们分开，使我们遵循文件的约定，并使字符串在编码时更容易找到和管理。

通常，我将文件分配到此方案中：

• errormessages.Resx
• logMessages.Resx
• ViewResources.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