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

Posted 2023-04-12

【中文标题】任何 .NET ORM 是不是支持开箱即用的本地化实体？

【英文标题】：Does any .NET ORM support localized entities out-of-the-box?任何 .NET ORM 是否支持开箱即用的本地化实体？

【发布时间】：2010-02-11 11:06:46

【问题描述】：

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

但是，当我想检索英语的 Product 类实例并期望 Name 属性的值是英语时，这似乎不太容易适应 ORM。

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

由于我在 Microsoft 堆栈中，因此 ORM 的明显选择是实体框架 4。EF4 中是否有任何功能支持这一点？

【参考方案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。

【参考方案2】：

我有完全相同的问题（本地化内容、MS 堆栈、ORM...），目前我使用 Resource/ResourceValue 表。 我将 Linq-to-SQL 与 PLINQO templates 一起使用，我对它进行了微调，以便在我的实体中生成自动本地化的属性。

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

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

缺点是：

INSERTS / UPDATES 的复杂性（必须使用 3 个表，但 Linq2Sql 使它不那么困难） 在 SQL 管理中浏览表很痛苦，因为文本列只是外键

我在寻找“最佳实践”解决方案时发现了这个问题，但我还没有找到。

【讨论】：

感谢您的意见。仅供参考，我们也使用了类似资源的表，但为了获得我们需要的性能而进行了大量缓存。这增加了一些复杂性，我宁愿不这样做。

【参考方案3】：

也许您需要进一步了解，我会使用 NHibernate 和一个拦截器来捕获实体的负载并根据应用程序的当前文化和某种存储本地化字符串的方式进行实体的本地化。

一些资源：

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

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

【讨论】：

这只是问题的一部分。