.NET Core本地化文件重构类名后同步问题咨询

两种方案的优劣势对比 #

• 按类/视图拆分本地化文件
  这种方案的优势很明确：资源文件和业务类一一对应，组织逻辑清晰，大型项目多人协作时不易出现资源键冲突，后期定位、修改特定功能的本地化文本效率更高。但正如你遇到的问题，项目初期类名、命名空间变动频繁时，必须同步修改对应的resx文件名和引用，确实会增加额外维护成本。

• 全局单资源文件（如StringResources.resx）
  这种方案的优势是初期维护简单，不用跟着类的变动调整文件结构，适合快速迭代的小项目或项目早期阶段。但缺点也很突出：随着项目规模扩大，资源键会越来越多，查找、管理会变得混乱，还容易出现不同功能模块用相同键名导致的内容冲突。

针对初期迭代的折中方案 #

如果想兼顾拆分方案的组织性，又不想被频繁的类名变动折腾，可以试试这些办法：

• 先用全局资源文件过渡，等项目结构、类名相对稳定后，再逐步将资源拆分到对应类/视图的resx文件中。
• 利用IDE的重构工具：比如Visual Studio的重命名功能（右键类名→重命名），它会自动同步更新关联的resx文件名以及代码中的IStringLocalizer<T>泛型参数，无需手动修改文件。
• 自定义本地化规则：通过实现自定义的IStringLocalizerProvider，或者给类添加特性指定对应的资源文件名，让资源文件的命名和类名解绑。比如给Foobar类加个[ResourceFile("Foo")]特性，这样即使类改名，也不用改动resx文件。

内容的提问来源于stack exchange，提问作者Terry