如何正确设计包含双重语言信息的类

Question

如果我的域对象应该包含2种语言的字符串属性，我应该创建2个单独的属性还是创建一个新类型的BiLingualString？

例如，在植物分类应用程序中，植物域对象可以包含Plant.LatName和Plant.EngName。

整个领域的双语言属性数量不多，大约6-8个，我只需要支持两种语言，信息应该同时以和两种语言呈现给用户界面。(因此这不是局部化)。在开发过程中，需求不会改变。

这看起来可能是一个简单的问题，但这个决定将对验证、持久性、对象克隆和许多其他事情产生影响。

我可以考虑使用新的dualString类型：

validation.

• Persistance：

• 验证:如果我要使用DataAnattations，Enterprise验证块，格式验证--这将需要更多的工作，对象图验证要比简单属性 iether或EF需要更多的工作来处理复杂的properties.
• OOP：--更复杂的对象初始化，我必须在构造函数中初始化这个新类型，然后才能使用it.
• Architecture:转换对象在层间传递，自动映射工具将需要更多的手工工作。

Answer 1

如果你100%肯定它将永远只有拉丁语和英语，我只会坚持最简单的解决方案-2字符串属性。它在UI中也更灵活，然后才有BiLingualString。而且，在持久化时，您不必处理复杂的类型。

Answer 2

在阅读您的问题时，我一直在考虑why not localization，但当我阅读information should be presented to UI in both languages at the same time.时，我认为使用属性是有意义的。

在本例中，我将为每种语言选择一个具有一个字符串的类，正如您提到的BiLingualString

public class Names
{
    public string EngName {get;set;}
    public string LatName {get;set;}
}

然后我会在我的主要植物类中使用这个类，就像这样

public class Plant: Names
{

}

Answer 3

为了帮助做出决定，我建议考虑这种行为在所有层上的一致性。如果您在业务对象上将它们公开为两个单独的属性，我还希望看到它存储为数据库记录中的两个单独的列，而不是存储在单独表中的相同属性的两个转换。用这种方式存储翻译确实很奇怪，但是你的理由听起来是合理的，而且6个属性也不是不可管理的。但是，请确保您不打算在将来添加更多语言。

如果您期望这个系统在某种程度上是动态的，因为您可能需要在某个时候添加另一种语言，那么以不同的方式实现这一点对我来说似乎更有意义，这样您就不必在需要支持一种新语言时更改模式。

我想要平衡的是:考虑到必须调整语言或属性以适应一种新语言的可能性，而不是将这些属性直接作为单独的属性公开，而不必将翻译作为一个单独的级别来加载，从而使其与优点(简单性)相适应。