文字列リソースファイルの命名スキームと管理

Question

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

一般的に、ファイルをこのスキームに分割します。

• errormessages.resx
• logmessages.resx
• viedresources.resx
• AppResources.resx

私は命名にあまり興奮していません。他の人が何を使っているのか疑問に思っています。たとえば、の代わりに AppResources （アプリケーションによる内部使用のための文字列）、私は多くのデモプロジェクトが使用するのを見てきました StringResources, Internal （ひどい！）など。

リソースの管理または標準命名スキームの管理に関するアイデア/逸話/提案が高く評価されています。

Answer 1

私は通常、このようなリソースを構成します：

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

• CommonResources.resx
  アクセス修飾子：public
  • 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