在多层架构中放置语言翻译的位置

Question

我构建了一个包含以下层的应用程序：

• WEB表现层
• 业务逻辑层 - BLL - 通过 HTTP Web 服务从 WEB UI 调用
• WindowsService - 运行时 - 通过 net.pipe 从 BLL 调用

也可以从第 3 方调用 BLL 以集成到其他客户的系统中。

假设在运行时甚至 BLL 中发生了验证错误。哪里放翻译比较好：

1. 在异常消息中 - 表示 我们必须从 WEB 发送 UICulture 层到下层
2. BLL 和运行时返回错误 代码或自定义异常派生 类型和翻译被执行 在WEB UI层
3. 其他方法

在 SOA 架构中支持多种语言的最佳实践是什么？

编辑： 我可能应该使用术语层而不是层。

• WEB UI 层在 ASP.NET Web 表单中实现，将部署在 IIS 下的服务器 A 上。
• BLL 和 Runtime 将部署在服务器 B 上，但由进程边界分隔（由于 WCF 服务，BLL 在 ASP.NET 工作进程下运行，而 Runtime 作为独立的 Windows 服务进程运行）。

Answer 1

我对您的问题的建议是一般性的，因为我不知道您正在使用的 .NET 平台的具体情况。

从您的问题中，我看到了两个截然不同的问题。

1. 您的网络表示层将依赖于语言。它将需要自定义 CSS、字体、间距甚至自定义内容。不要自欺欺人，这将是不需要的。这是人们在国际化 Web 应用程序时最初犯的最大错误之一。您将需要另一种语言风格。因此，如果您使用的是模板方法，您可以将大部分语言内容直接放在与语言相关的模板中。

2. 从您的问题描述看来，您还需要处理本地化错误消息。有两种方法：您可以拥有一个语言文件，当使用资源文件解决方案引发错误时，您可以在其中进行本地化。另一种方法是让您的错误消息使用通用标识符和参数，并让另一层捕获消息并将其本地化。我自己更喜欢前一种解决方案，因为它更简单。

还请记住，如果您将错误消息写入日志文件，则错误消息采用开发人员可以阅读的语言。同样，对于在 GUI 中显示给用户的错误，您将需要某种方式让用户向不说用户语言的开发人员识别错误。这可以通过使用数字来完成 - 我更喜欢使用像 DATABASE_ERROR_BAD_QUERY 这样的短键。

Answer 2

翻译应由表示层处理，因为它与视图相关。可以添加到消息中的上下文越多越好，业务逻辑可能不知道上下文也不应该知道。

我使用的一种方法如下：

• 业务逻辑抛出唯一的、已定义的 可用作键的错误代码 进入资源包以获得 翻译的消息。

• 表示层维护一个文本 包含所有错误代码的包 翻译独立于 通用表示层代码。

• 表示层依赖于
  业务逻辑和文本 包。

• 业务逻辑的第 3 方客户端，例如 Web 服务， 可以选择包含文本 如果需要，将其打包为依赖项 标准错误代码翻译。 否则他们可以处理错误 业务逻辑抛出的代码 他们自己的。

Answer 3

我不太确定您对 WEB UI 的定义是什么。如果您使用 MVC 模式，控制器将负责在 UI 中显示正确的语言版本，而文本本身将位于视图层中。我不明白的是，控制器在您的架构中扮演什么角色。 BLL 是指只包含处理逻辑，不包含 UI 和 Services 之间的通信吗？如果是这样，那么 Web UI 层可能会包含本地化逻辑。

我还要说，这在很大程度上取决于您在项目中使用的技术。例如，ASP.NET 有一个可以使用的内置本地化模型。我并不是说它应该作为一个例子，即使相反 - ASP.NET 打破了关注点分离。但我认为这是一个问题，在不同的自定义架构模型中会有非常不同的解决方案，就像你的情况一样。

Answer 4

根据您的应用程序的结构，您可能需要在两个位置进行国际化：

1) 软件本身。菜单、对话框、消息、标签、报告等。

2) 内容。当您的应用程序以多种语言运行时，可能需要处理多种语言的内容。

我很幸运能够将管理工具和发布逻辑分离到不同的层（到目前为止）。

首先，考虑将语言翻译管理和生成逻辑（资源包等）放在业务逻辑中。因此，对于所有翻译，您需要一种快速同步所有数据条目的方法它们从母语（英语）以所有语言添加到系统中，然后填充和管理这些语言。因此，例如，如果您使用资源包，请从数据库中为所有语言生成 rb 文件。

其次，在表示层发布语言翻译逻辑。它更多地与表示和格式有关。您不可避免地会遇到日期、时间、货币等的本地化问题，您可以在这里很好地处理这些问题。您可能会也可能不会构建自己的库来发布这些内容，因为您的编程语言的灵活性可能允许也可能不允许。

如果您能提供更多详细信息，我相信这里的每个人都可以提供其他见解。

祝你好运！