6

似乎有两种不同的方法。ASP.NET 框架为我们提供了一种通过将 UI 字符串放入资源（如 UserProfile.en.resx、UserProfile.fr.resx 等）来本地化页面的简单方法。

另一种方法是将所有字符串放在数据库中的单独表中，然后使用一些自定义机制根据当前活动的语言/文化设置检索它们。

据我了解，数据库方法对于大型项目（例如企业软件）更为典型。它还有一个好处，您可以将对该数据库的外部访问权限授予翻译公司。有资源就难了。

另一方面，从数据库中检索所有静态字符串是额外的流量和负载开销。我看不出一个相对较小的网站这样做有什么好处。“小”的意思不是流量，而是页面的数量和复杂性。

我个人更喜欢将资源用于我的私人项目。这绝对是个坏主意吗？

顺便问一下，我还能在 ASP.NET MVC 中使用资源吗？

任何想法表示赞赏。

编辑：只有一个答案，不能相信这个问题对任何人都不感兴趣。没有人愿意分享他们的意见？

4

2 回答 2

3

将两者结合起来。您可以编写一个使用数据库而不是资源文件的自定义资源提供程序，这样您就不必自己进行繁重的绑定文本（也就是说，让我们面对它，容易出错），您只需使用 ASP。 NET 的本地化功能。MSDN 有一个很好的演练Michelle Leroux Bustamante

于 2009-04-09T10:48:19.577 回答
2

我更喜欢将所有这些信息保存在数据库中，而不是依赖于 asp.net 资源文件。

我所做的是将我的常用控件（如标签）子类化并覆盖渲染方法。此方法查找当前文化并通过查找我的数据结构相应地设置适当的标题

关于将它们保存在数据库中时的性能 - 这就是我所做的：在我的 application_start 事件中，我只是将我所有的文化特定描述加载到一个自定义对象中并将它缓存得很长。这样我就不必访问数据库，直到我的缓存过期或我强制它过期

到目前为止，我们从未在遵循这种方法的性能方面遇到任何问题。说了这么多-请注意，我并不是说使用资源文件也是一个不好的选择

但如果给我一个选择，我更喜欢数据库方法而不是资源文件方法

于 2009-04-08T10:58:59.030 回答