处理跨多个应用程序和共享库（.NET）

我们正在开发的产品，将在下面的方式来使用多国语言：可通过多种产品中使用处理跨多个应用程序和共享库（.NET）

各种共享库。我预计这些库将主要需要访问包含错误消息/异常的字符串资源。
各种基于最终用户的应用程序，旨在作为PC上的独立应用程序运行。他们将被要求在部署/安装时支持多种语言。
可能需要在部署时或可能在运行时支持多种语言（即最小或零停机时间）的各种网站。如果全球访问，网站可能需要同时支持多种语言。
我们可能被要求允许客户访问我们的语言文件进行编辑。我们不希望允许他们访问我们的源代码（除了资源文件/ dll）以实现此目的。
我们可能需要包含一个工具来记录我们的母语（在这种情况下是英语）的异常，并以翻译后的语言显示它们。这将有助于我们在现场调试我们的客户解决方案。

我已经知道像RCWinTrans这样的产品，并且在VC++/MFC应用程序中处理多种语言。然而，我们在这里面临的要求更为广泛，因此要求我们做出一些前期决策，这些决策可能难以长期改变，因此理想情况下我们希望现在做出最佳选择。

根据我自己的知识，我有几个问题，虽然我可能会错过一些技巧与.net将愉快地收到。这里是我的问题：

什么是最好的？将我们所有的资源放入每个VS解决方案的独立DLL中，或者将资源放入每个VS项目中。我根据解决方案看到的方式更易于管理，修改和允许客户访问。每个项目解决方案虽然看起来比较清晰，并且使得各个项目更加便携这种方法适用于我们基于共享库的解决方案以及基于终端应用的解决方案。
上述解决方案是否仍然支持网站？有没有更好的办法？这种方式是否需要停机？
是否有可能一次加载两个独立的资源文件，即如果我们想用英文记录例外情况，但是在翻译后的语言中为它们提供了食物链（作为例外消息）？我们可以使用像AOP这样的自动化技巧吗？

由于事先

罗杰

来源

2010-01-18 RogerD

你有没有使用Inversion of Control container像StructureMap或Unity考虑？这可能会允许您将默认资源与项目（恕我直言，IMHO最有意义）一起保留，同时仍允许客户根据需要在本地覆盖资源。

举个例子，假设您有以下接口：

public interface IResourceSupplier 
{ 
    // Returns the localized text for a given identifier. 
    string Localized(string identifier); 

    // Returns the invariant (English) text for a given identifier. 
    string Invariant(string identifier); 
}

使用国际奥委会，你可以为这将检查用户提供的替代解决方案创建一个集中的资源供应商。如果没有提供用户覆盖，则可以查询每个项目特定的资源提供者（在应用程序启动时检测到），直到找到返回所需资源的资源。

显然，根据您的需要，您可能需要调整性能，例如通过缓存经常使用的资源。使用IOC的优点是，只要界面不变，插入替代实现可能是一项相对简单的任务。

这有帮助吗？

来源

2010-01-18 17:23:40

嗨，理查德，谢谢你。我知道IOC和依赖注入，我理解它的优点。您向我提供了一些关于如何解决问题的好主意。 – RogerD 2010-01-21 13:04:50

处理跨多个应用程序和共享库（.NET）

回答

相关问题