Глобализация с NHibernate - PullRequest
Новая
       21

Глобализация с NHibernate

2 голосов
/ 27 апреля 2009

Как вы будете строить свои доменные объекты и создавать соответствующие им файлы сопоставления NHibernate для многоязычного приложения. Часть пользовательского интерфейса хранится в файлах ресурсов, но пользовательские данные должны попадать в базу данных.

Я хочу сделать следующее: 

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

Я нашел следующую статью, которая очень близка: http://ayende.com/Blog/archive/2006/12/26/LocalizingNHibernateContextualParameters.aspx Поскольку я новичок в NHibernate, я не уверен, что это будет отлично работать для корпоративных решений.

У вас есть другие предложения? Как вы решаете такой сценарий?

Он должен быть гибким:

  • Вставка, обновление и выбор
  • Коллекция

Ответы [ 3 ]

3 голосов
/ 27 апреля 2009

Пост Ayendes - отличное начало того, как он должен быть оформлен.

Отлично подойдет для корпоративных решений. Имена в отдельной таблице похожи на любой другой список значений. Особенность в том, что он фильтруется в отображении.

Редактировать - Опции:

Использование другого объекта для редактирования данных

Существует сущность Product, в которой все имена представлены в виде списка. LocalizedProduct имеет только название текущего языка.

Получить отфильтрованный объект

  • либо сопоставив его, как описано в блоге, с фильтром.
  • , выбрав его с помощью преобразователя результатов (Transformers.AliasToBean) или с помощью «выбрать новый LocalizedProduct (id, name, приз ...)». LocalizedProduct не будет отображаться в этом случае. Должен быть ориентирован на кэш второго уровня.

Если у вас много ссылок на Product, вероятно, не очень хорошо иметь два класса, потому что вы не знаете, какой класс должен иметь ссылка.

Использовать один и тот же объект для редактирования и отображения 

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

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

Существуют свойства для локализованного названия продукта (get) и для всех названий продуктов.

  • не фильтруйте их вообще :-) Существует небольшая нагрузка на сеть. если у вас есть только от 3 до 5 языков, это не так уж плохо. если у вас есть 20 или больше, вероятно, лучше отфильтровать имена.
  • используйте (необязательный) фильтр, как описано в блоге, но в названиях продуктов
  • использовать (необязательный) ResultTransformer (CriteriaUtil.AliasToEntityMap) для фильтрации имен.

Если честно, я бы выбрал вариант, который не требует фильтров в файлах сопоставления. Фильтры относятся к запросам, где их удобнее обслуживать.

0 голосов
/ 24 июня 2009

Подход, упомянутый в качестве ответа, подробно объяснен здесь

0 голосов
/ 28 апреля 2009

Здесь - это сообщение Гэвина Кинга I, которое, похоже, предлагает другое решение.

...