Globalization with NHibernate

Globalization with NHibernate

狼亦尘 发布于 2021-11-27 字数 928 浏览 829 回复 3 原文

How would you build your domain objects and create its respective NHibernate mapping files for a multi language application. The UI part is stored in resource files but user data needs to go into the database.

I want to do the following:

Product p = DALProduct.getByID(2)
p.name //results in the language of the current UICulture

I have found the following article which is really close:
http://ayende.com/Blog/archive/2006/12/26/LocalizingNHibernateContextualParameters.aspx
As I am new to NHibernate I am not sure if that will perfectly work for enterprise solutions.

Do you have other suggestions? How do you solve such scenario?

It should be flexible to:

  • Inserting, Updating and selecting
  • Collections

如果你对这篇文章有疑问,欢迎到本站 社区 发帖提问或使用手Q扫描下方二维码加群参与讨论,获取更多帮助。

扫码加入群聊

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

む无字情书 2022-06-07 3 楼

The approach mentioned as an answer has been explained in detail here

墨小墨 2022-06-07 2 楼

Here is Gavin King's Post I which seems to offer a different solution.

标点 2022-06-07 1 楼

Ayendes post is a great start how it should be designed.

It will perfectly work for enterprise solutions. The names in a separate table is like any other list of values. The special thing is, that it is filtered in the mapping.

Edit - Options:

Use another entity to edit the data

There is Product entity that has all the names as list. LocalizedProduct has only the current languages name.

Get the filtered entity

  • by either mapping it as described in the blog, with the filter.
  • by selecting it with a result transformer (Transformers.AliasToBean) or with 'select new LocalizedProduct(id, name, prize ...)'. LocalizedProduct would not be mapped in this case. Should be second-level-cache-friendly.

If you have many references to Product, it is probably not so nice to have two classes, because you don't know which class the reference should have.

Use the same entity for editing and displaying

class Product
{
  string LocalizedName 
  { 
    get { return AllProductNames[Thread.CurrentThread.CurrentCulture.LCID]; }
  }

  IDictionary<int, string> AllProductNames { get; private set; }
}

There are properties for a localized product name (get) and all product names.

  • don't filter them at all :-) There is a bit of network overhead. if you have only 3 to 5 languages, it is not so bad. if you have 20 or more, it's probably better to filter the names.
  • use a (optional) filter as described in the blog, but on the product names
  • use a (optional) ResultTransformer (CriteriaUtil.AliasToEntityMap) to filter the names.

To be honest, I would choose a option that dies not need filters in the mapping files. Filters belong to queries where they are more maintainable.