任何.NET ORM是否支持开箱即用的本地化实体？

Question

我需要在数据库中存储本地化的实体（例如一个产品，其名称不同，英文和丹麦文）。有几种众所周知的方式可以做到这一点，例如拥有某种包含本地化列值的资源表。

但是，当我想用​​英语检索产品类的实例并期望Name属性的值为英文时，这似乎不容易适合ORM。

我不想重新发明轮子，我认为这是一个非常普遍的问题。 任何ORM支持实体本地化的开箱即用？

因为我在微软的堆栈上，而ORM的明显选择是实体框架4. EF4中有没有什么特性支持它？

Answer 1

AFAIK EF4不提供这样的事。

Dmitri Maximov写了一系列好后覆盖实现本地化DataObjects.Net的，该信息可能对你有所帮助，即使你使用（或打算使用）任何其他框架：

• Localization support, part 1. Theory
• Localization support, part 2. Domain modeling
• Localization support, part 3. CRUD operations
• Localization support, part 4. Queries - 有点过时，我还是建议你查看code of working localization sample。

Answer 2

也许你需要更进一步，我会使用NHibernate和拦截器来捕获实体的负载，并根据应用程序的当前文化和实现本地化的字符串来进行实体的本地化。

一些资源：

http://elegantcode.com/2008/05/15/implementing-nhibernate-interceptors/

http://knol.google.com/k/fabio-maulo/nhibernate-chapter-11/1nr4enxv3dpeq/14#

Answer 3

我有完全相同的问题（本地化内容，MS堆栈，ORM ...），并与资源/ ResourceValue表一起去的那一刻。 我使用Linq-to-SQL与PLINQO templates，我稍微调整了在我的实体中生成自动本地化属性。

该模板检测资源表的外键并创建适当的列。

例如，如果我有一个带有int NameID FK列的产品表，它将在我的Product类中创建一个string Name属性，根据当前线程文化返回相应的值。

的缺点是：

• 的插入/更新的复杂性（必须与3桌玩，但LINQ2SQL让它不是那么困难），在SQL管理
• 浏览表是不好受，因为文本列只是国外钥匙

我发现这个问题后，“最佳实践”的解决方案，但我还没有找到一个呢。