ASP.NET中的全局资源与本地资源
我们使用resx文件来本地化我们的Web应用程序。 我们通常创build本地resx文件（映射到特定页面），当只有一个页面使用特定的短语，以及一个全球resx文件，当多个页面需要短语。
但是关于全局resx文件的好处是它们是一个类，你可以调用像调用一个类的属性这样的短语：
Resource.UI.iNotFound
所以我在想 – 为什么要有本地的resx文件呢？ 为什么不为整个应用程序使用一个全局resx文件，这样避免调用不存在的短语的运行时错误？
我确信有一个很好的答案，我只是不知道它是什么….
我一直在寻找指导方针，并在MSDN中发现：
在全局和本地资源文件之间进行select
您可以在Web应用程序中使用全局和本地资源文件的任意组合。 通常，当您要在页面之间共享资源时，将资源添加到全局资源文件。 当您想以编程方式访问文件时，全局资源文件中的资源也是强types的。
但是，如果将所有本地化资源存储在其中，则全局资源文件可能会变大。 如果不止一个开发人员在不同的页面上工作，而是在一个资源文件中，则全局资源文件也可能更难以pipe理。
本地资源文件使pipe理单个ASP.NET网页的资源变得更加简单。 但是你不能在页面之间共享资源。 此外，如果您有许多页面必须本地化为多种语言，则可能会创build大量本地资源文件。 如果网站较大，文件夹和语言较多，则本地资源可以快速扩展应用程序域中的程序集数量。
当您更改默认资源文件（本地或全局）时，ASP.NET会重新编译资源并重新启动ASP.NET应用程序。 这可能会影响您的网站的整体性能。 如果您添加卫星资源文件，它不会导致重新编译资源，但ASP.NET应用程序将重新启动。
所以，编程团队真的应该权衡每种方法的优缺点，并select对他们有利的方法。
Joe90 – 我不得不说，根据我的经验，我不能同意在整个项目中分散pipe理大量本地资源文件比pipe理全局资源文件更容易。 没有什么可以一次又一次地停止重复相同的翻译，而且很难追查。 访问全球资源文件很容易在一个团队内协调，多个用户一眼就可以看到他们所需的翻译是否已经完成。
我开始时的策略与Lea完全相同 – 即从一个本地资源文件开始，然后将其移动到一个全局资源文件，如果它被多次引用。 这很快就变成了pipe理的麻烦，我现在每次都转向使用全局资源文件。
微软似乎没有明确的指导方针，甚至是如何实施这两种方法，这样我们才有可能猜测！
我猜比较/收益是本地资源文件只需要重新编译它们相关的文件，而改变全局资源文件似乎需要重新编译整个网站 – 会话状态的固有损失等。因此需要在更新过程中使网站脱机以确保安全。
我在一个产品上至less有10个开发人员的开发团队，我们为每个站点使用一个全局resx。
合并这个大的resx文件的问题应该在我看来不是一个问题。
如果您有10位开发人员自己在网站上设置语言，那么您如何在网站上获得统一的expression方式？ 开发人员通常倾向于擅长代码而不是语法expression。 （我自己是开发者）
语言专家应该编辑resx文件并将其locking给开发人员！
全局资源文件是翻译的最佳方法。 关键是使用命名约定，如string名称的前几个字母的页面名称缩写，以便您可以轻松地find每个网页基础的资源。 尝试在多个页面上重复使用许多短语会给译员带来更多的困惑。
您可以使用缺less页面命名约定（前几个字母没有页面名称缩写）来定义可重复使用的短语，如“是”，“否”，“BTN_OK”，“BTN_Cancel”，“QTN_AreYouSure”等。 RESX的绝大多数行都是针对每个页面的，您不应该专注于尽可能重复使用。 在整个文件中更改一个短语可以在几分钟内仔细完成，在需要时使用文本查找/replace。
