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

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