Просмотр исходного текста страницы Подвалы Вавилонской башни, или Об интернационализации баз данных с доступом через ORM

''<blockquote>[[:Категория:Владислав Иофе (Статьи)|Владислав Иофе]], наш архитектор приложений, опубликовал на портале [https://habrahabr.ru/ «Хабрахабр»] пост, посвященный хранению и обработке многоязычных данных. Какие способы хранения существуют? Какими преимуществами и&nbsp;недостатками они&nbsp;обладают и&nbsp;есть ли&nbsp;идеальный вариант? Об&nbsp;этом&nbsp;— в&nbsp;материале [https://habrahabr.ru/company/custis/blog/313690/ «Подвалы Вавилонской башни, или Об интернационализации баз данных с доступом через ORM»].</blockquote>''
== Введение ==
В [[:Подмостки_для_Вавилонской_башни,_или_О_собственных_типах_данных_для_многоязычных_приложений|предыдущей статье]] на&nbsp;примере доменной сущности товара мы&nbsp;рассмотрели собственные типы данных для&nbsp;многоязычных приложений. Мы&nbsp;научились описывать и&nbsp;использовать атрибуты сущностей, имеющие значения на&nbsp;различных языках. Но&nbsp;вопросы хранения и&nbsp;обработки в&nbsp;реляционной СУБД, а&nbsp;также проблемы эффективной работы в&nbsp;коде приложения до&nbsp;сих&nbsp;пор&nbsp;актуальны.

IT-сообщество использует различные способы хранения многоязычных данных. Способы эти кардинально различаются эффективностью запросов, устойчивостью к&nbsp;добавлению новых локализаций, объемом данных, удобством для&nbsp;приложения-потребителя. 

Однако в&nbsp;индустрии все&nbsp;еще нет решения ''Database Internationalization for&nbsp;Dummies''. Вместе с&nbsp;вами мы&nbsp;попробуем немного заполнить этот пробел: опишем возможные способы, оценим их&nbsp;преимущества и&nbsp;недостатки, выберем эффективные. Мы&nbsp;не&nbsp;собираемся изобретать серебряную пулю, но&nbsp;сценарий, который будем рассматривать, довольно типичен для&nbsp;корпоративных приложений. Надеемся, многим он&nbsp;окажется полезен.

Приведенные в&nbsp;статье фрагменты кода&nbsp;— на&nbsp;языке C#. На&nbsp;GitHub можно найти [https://github.com/CUSTIS-public/CUSTIS.i18n.DAL примеры реализации] механизмов интернационализации с&nbsp;использованием двух различных связок ORM и&nbsp;СУБД: [http://nhibernate.info/ NHibernate]&nbsp;+ [http://www.oracle.com/technetwork/database/enterprise-edition/overview/index.html Oracle Database] и&nbsp;[https://docs.microsoft.com/en-us/ef/#pivot=efcore Entity Framework Core]&nbsp;+ [https://www.microsoft.com/en-us/sql-server/developer-get-started/ SQL Server]. Разработчикам, использующим упомянутые ORM, будет интересно узнать конкретные приемы и&nbsp;трудности работы с&nbsp;многоязычными данными, а&nbsp;также блокирующие дефекты фреймворков и&nbsp;перспективы их&nbsp;устранения. Изложенные ниже принципы и&nbsp;примеры работы с&nbsp;многоязычными данными легко перенести и&nbsp;на&nbsp;другие языки и&nbsp;технологии.

== Условия задачи ==
Наше приложение должно работать сразу с&nbsp;несколькими языками. На&nbsp;любом из&nbsp;них в&nbsp;зависимости от&nbsp;окружения пользователя будут отображаться и&nbsp;вводиться оперативные и&nbsp;справочные данные. При&nbsp;этом существуют сценарии, требующие умения в&nbsp;рамках одной сессии работать с&nbsp;данными сразу на&nbsp;всех языках. 

Для&nbsp;примера рассмотрим уже знакомую нам доменную сущность товара, имеющую наименование на&nbsp;различных языках. 
<code-csharp>public class Product
{
    public long Id {get; set; } 
    public String Code { get; set; }
    public MultiCulturalString Name { get; set; }
}</code-csharp>
Сформулируем требования к&nbsp;хранению и&nbsp;обработке данных сущности с&nbsp;многоязычными атрибутами:

* Хранение, чтение и&nbsp;запись таких сущностей должны быть и&nbsp;через ORM (преимущественно), и&nbsp;средствами СУБД (хотя бы для&nbsp;целей сопровождения); 
* Многоязычных атрибутов может быть несколько.
* Должно выполняться требование [https://docs.microsoft.com/en-us/globalization/localizability/overview ''локализуемости''].
* Должна быть возможность быстрого поиска и&nbsp;сортировки по&nbsp;локализованным значениям многоязычного атрибута:
** только для&nbsp;заданной локали;
** с&nbsp;учетом заданного алгоритма обработки альтернативных ресурсов (если для&nbsp;запрошенной локали значение отсутствует).
* Должна быть возможность поиска по&nbsp;локализованным значениям многоязычного атрибута среди всех локалей.
* Должна быть возможность расширения для&nbsp;локализации не&nbsp;только строковых атрибутов, но&nbsp;и&nbsp;атрибутов других типов (полезен <code>MultiCultural<T></code>).
* Объемы хранимых данных и&nbsp;трафика между БД и&nbsp;приложением должны быть допустимыми.

Напомним, что&nbsp;алгоритм обработки альтернативных ресурсов <code>IEnumerable<CultureInfo> IResourceFallbackProcess.GetFallbackChain(CultureInfo initial)</code> может возвращать различные порядки поиска локализаций для различных начальных локалей <code>initial</code>:

* для <code>initial</code> локали ru-RU: <code>ru-RU -> ru</code>;

* <code>initial</code> локали en-US: <code>en-US -> en -> ru</code>;
 
* <code>initial</code> локали kz-KZ: <code>kz-KZ -> kz -> ru</code>;
 
* <code>initial</code> локали zh-CH: <code>zh-CH -> zh-CHS -> zh-Hans -> zh -> en</code>.

== Обзор существующих возможностей ==

=== СУБД ===

Какие же&nbsp;фичи есть в&nbsp;крупнейших современных СУБД для&nbsp;интернационализации? Это:

* Юникод;

* Collation (правила сравнения символов, регистрочувствительность и&nbsp;пр.);

* Дата-время с&nbsp;часовым поясом/смещением.

Эти фичи поддерживают многие крупные вендоры. Приведем ссылки на некоторые статьи:

* Microsoft: [https://msdn.microsoft.com/en-us/library/ms190245.aspx International Considerations for Databases and&nbsp;Database Engine Applications];

* Oracle: [https://docs.oracle.com/database/121/NLSPG/ch6unicode.htm#NLSPG325 Designing Database Schemas to&nbsp;Support Multiple Languages].

Однако никаких «стандартных» схем хранения многоязычных данных не&nbsp;существует. Нет их и&nbsp;в&nbsp;самом свежем стандарте SQL:2016.

Из&nbsp;любопытных академических публикаций можно отметить кандидатскую диссертацию экс-главы [https://www.microsoft.com/en-us/research/group/multilingual-systems/ Исследовательской группы многоязычных систем] Microsoft [https://www.microsoft.com/en-us/research/publication/multilingual-information-processing-on-relational-database-architectures/ Multilingual Information Processing on Relational Database Architectures], 2005. В&nbsp;работе рассматриваются проблемы кросс-языковых запросов, многоязычные операторы соединения (multilingual join operators), алгебра запросов для&nbsp;нового типа хранения многоязычных данных и&nbsp;упомянутых операторов.

=== ORM ===

Документация по&nbsp;NHibernate порадовала присутствием статьи [http://nhibernate.info/doc/howto/various/localization-techniques Localization techniques]. В&nbsp;ней рассматриваются два способа хранения (с&nbsp;вариациями):
* Одна колонка, в&nbsp;которой хранится пользовательский тип данных&nbsp;— словарь ''локаль-данные''.
* Отдельные таблицы для&nbsp;хранения локализованных атрибутов (1-2 шт.).

Примечательно, что&nbsp;в&nbsp;этой статье даже не&nbsp;упоминается достаточно очевидный и&nbsp;популярный способ хранения&nbsp;— многоколоночный (колонка на&nbsp;локаль).

По&nbsp;Entity Framework значимых материалов найти не&nbsp;удалось.

== Сравнение хранений ==

Для&nbsp;начала сформируем критерии сравнения. Для&nbsp;этого описанные выше требования переформулируем в&nbsp;более технические. Как&nbsp;мы убедимся далее, все они довольно жесткие.

'''Локализуемость.''' Изначально требование означает отсутствие изменений в&nbsp;коде, когда новая локализация добавляется в&nbsp;приложение. Применительно к&nbsp;приложениям с&nbsp;локализованными данными мы, например, можем говорить об&nbsp;отсутствии изменений в&nbsp;схеме данных и&nbsp;маппингов ORM.

'''Поиск и&nbsp;сортировка для&nbsp;заданной локали.''' В&nbsp;терминах многоязычной строки это означает возможность использовать индексы по&nbsp;результатам функции <code>String MultiCulturalString.GetString(IResourceFallbackProcess resourceFallbackProcess, CultureInfo culture, bool useFallback)</code> для&nbsp;всех осмысленных в&nbsp;данном приложении комбинаций значений ее&nbsp;параметров. Экземпляр <code>IResourceFallbackProcess</code> в&nbsp;приложении, вероятно, единственный, при&nbsp;<code>useFallback = false</code> значение <code>resourceFallbackProcess</code> роли не&nbsp;играет, поэтому число необходимых индексов по&nbsp;локализованным данным не&nbsp;более <code>2N</code>, где <code>N</code>&nbsp;— число различных локалей, используемых во&nbsp;всех записях в&nbsp;многоязычном атрибуте.

'''Поиск среди всех локалей.''' Требуется поддержка функции вида <code>MultiCulturalString.FindLocalizedStringCulture(String localizedString)</code> с&nbsp;типом возвращаемого значения <code>CultureInfo</code>.

'''Поиск подходящей локализации.''' Локаль пользователя всегда специфичная, то&nbsp;есть определяет не&nbsp;только язык, но&nbsp;и&nbsp;региональные параметры. А&nbsp;для&nbsp;хранения в&nbsp;большинстве случаев достаточно использовать нейтральные локали (не&nbsp;задающие специфику региона), «ближайшие» к&nbsp;выбранным специфичным.

Поэтому из&nbsp;приведенных выше десяти локалей нам достаточно предусмотреть хранение только для&nbsp;четырех нейтральных: <code>ru, en, kz, zh-Hans</code>. А&nbsp;в&nbsp;ORM можно поддержать функционал приведения специфичной локали к&nbsp;нейтральной при&nbsp;присваивании атрибута и&nbsp;(или)&nbsp;сохранении сущности.

'''Пригодность для&nbsp;ORM.''' У&nbsp;выбранного ORM должно быть достаточно точек расширения, чтобы&nbsp;мы смогли претворить в&nbsp;жизнь все наши фантазии о&nbsp;многоязычном хранении. Иначе [https://goo.gl/s89eAY придется писать] новый фреймворк.

==== Многоколоночное хранение ====
Этот вариант требует заранее знать список необходимых локализаций. А&nbsp;для&nbsp;каждой новой используемой локали нам понадобится добавлять новую колонку и&nbsp;пару индексов. И&nbsp;так для&nbsp;каждого многоязычного атрибута во&nbsp;всех таблицах локализуемых сущностей. Вероятно, придется изменять маппинги ORM в&nbsp;коде и&nbsp;(или)&nbsp;конфигурации клиента БД, особенно для&nbsp;статических моделей.

Но&nbsp;не&nbsp;стоит сразу расстраиваться. Изменения в&nbsp;коде и&nbsp;конфигурации, скорее всего, не&nbsp;станут большой проблемой для&nbsp;приложения, в&nbsp;котором заранее известен и&nbsp;редко меняется список используемых локалей и&nbsp;(или)&nbsp;используются динамические сущности. Кроме того, как&nbsp;увидим далее, требование локализуемости так&nbsp;или&nbsp;иначе придется ослаблять для&nbsp;всех рассматриваемых вариантов.
[[File:Иофе_код_1.png||400px|center]]

С&nbsp;созданием индексов для&nbsp;каждой из&nbsp;<code>name_*</code>-колонок для случая, когда мы не&nbsp;используем поиск подходящей локализации, вроде все очевидно. Но&nbsp;как будет выглядеть запрос, в&nbsp;котором должен работать <code>IResourceFallbackProcess</code>?

Рассмотрим, например, такой запрос:

<code-csharp>var enUS = CultureInfo.GetCultureInfo("en-US");
var productName = "...";
var result = GetRepository<Product>()
   .Where(p => p.Name.ToString(enUS) == productName)
   .SingleOrDefault();</code-csharp>

Думаю, вы согласитесь, что&nbsp;он вполне может быть реализован следующим SQL-запросом:

<code-sql>SELECT pr.id_product, pr.code, pr.name_ru, pr.name_en, pr.name_kz, pr.name_zh_hans
FROM t_product pr
WHERE isnull(pr.name_en, isnull(pr.name_ru, '')) LIKE @p1
ORDER BY isnull(pr.name_en, isnull(pr.name_ru, '')), pr.id_product</code-sql>

Чтобы получать «честный» <code>null</code> вместо пустой строки, когда запрашиваемое значение отсутствует, с&nbsp;точки зрения многоязычной строки следует использовать одну из&nbsp;перегрузок <code>MultiCulturalString.GetString</code>. Тогда выражение фильтрации в&nbsp;SQL немного упростится:

<code-sql>SELECT pr.id_product, pr.code, pr.name_ru, pr.name_en, pr.name_kz, pr.name_zh_hans
FROM t_product pr
WHERE isnull(pr.name_en, pr.name_ru) LIKE @p1
ORDER BY isnull(pr.name_en, pr.name_ru), pr.id_product</code-sql>

Получаем, что&nbsp;еще хотя&nbsp;бы по&nbsp;одному индексу на&nbsp;локаль нам необходимо строить по&nbsp;выражению с&nbsp;<code>isnull</code>, которое является SQL-отображением цепочки поиска альтернативных ресурсов. Такие индексы обычно называют функциональными, в&nbsp;SQL Server это&nbsp;индексы над&nbsp;вычислимыми колонками. В&nbsp;приведенном выше описании таблицы <code>t_product</code> эти индексы имеют суффикс <code>_stdfallback</code>.

О&nbsp;виде запроса в&nbsp;случае поиска строки среди всех локализаций мы предоставим читателю возможность пофантазировать.

Такой способ хранения и&nbsp;доступа реализован для&nbsp;одного из&nbsp;клиентов нашей компании.

==== Одноколоночное сериализованное хранение ====
В&nbsp;этом варианте многоязычный атрибут занимает только одну колонку. Многоязычная строка может быть сериализована как в&nbsp;бинарном, так&nbsp;и&nbsp;в&nbsp;человекочитаемом виде. Или, например, в&nbsp;Oracle колонка может иметь объектный тип.

Учитывая современные тенденции развития стандарта SQL, стоит обратить внимание на&nbsp;XML- или JSON-хранение. Oracle Database, SQL Server, DB2, PostgreSQL, MySQL имеют довольно серьезную поддержку XML и&nbsp;(или)&nbsp;JSON.

Принимая такое решение, нам необходимо позаботиться о&nbsp;возможности получения (а&nbsp;кому-то&nbsp;— и&nbsp;записи) локализованных значений средствами СУБД. Универсальным&nbsp;и хорошо инкапсулирующим конкретный вариант сериализации способом будет создание пользовательской скалярной функции, которая принимает на&nbsp;вход сериализованное значение, локаль и&nbsp;цепочку для&nbsp;поиска подходящей локализации, а&nbsp;возвращает локализованную строку.

[[File:Иофе_код_2.png||400px|center]]

SQL-запрос для&nbsp;поиска будет выглядеть примерно&nbsp;так:

<code-sql>SELECT pr.id_product, pr.code, pr.name
FROM t_product pr
WHERE McsGetString(pr.name, 'en', 'en,ru') LIKE @p1
ORDER BY McsGetString(pr.name, 'en', 'en,ru'), pr.id_product</code-sql>

При&nbsp;появлении новой локали нам все&nbsp;же&nbsp;придется добавлять новые функциональные индексы по&nbsp;результатам функции <code>McsGetString</code>. Добавление только индексов&nbsp;— более безопасное действие, чем&nbsp;добавление новых колонок. В&nbsp;отличие от&nbsp;многоколоночного хранения маппинги ORM, вероятно, изменять не&nbsp;придется.

==== Реляционное хранение ====

Здесь мы&nbsp;заводим отдельную таблицу для&nbsp;хранения локализованных значений. Вариаций такого хранения множество. Рассмотрим только один из&nbsp;них.
[[File:Иофе_код_3.png||500px|center]]

SQL-запроc для&nbsp;поиска только по&nbsp;одной локали выглядит довольно просто:

<code-sql>SELECT pr.id_product, pr.code, pl.name
FROM t_product pr
  LEFT JOIN t_product_localizable pl 
    ON pr.id_product = pl.id_product AND pl.locale = 'en'
WHERE pl.name LIKE @p1
ORDER BY pl.name, pr.id_product</code-sql>

SQL-запроc с&nbsp;учетом поиска подходящих локализаций уже&nbsp;более громоздкий:

<code-sql>SELECT pr.id_product, pr.code, pl_en.name, pl_ru.name
FROM t_product pr
  LEFT JOIN t_product_localizable pl_ru 
    ON pr.id_product = pl_ru.id_product AND pl_ru.locale = 'ru' 
  LEFT JOIN t_product_localizable pl_en 
    ON pr.id_product = pl_en.id_product AND pl_en.locale = 'en' 
WHERE isnull(pl_en.name, isnull(pl_ru.name, '')) LIKE @p1
ORDER BY isnull(pl_en.name, isnull(pl_ru.name, '')), pr.id_product</code-sql>

Такой запрос преподносит нам целый букет сюрпризов. 

Во-первых, стоимость запроса уже заметно выше, чем&nbsp;в&nbsp;предыдущих вариантах. 

Во-вторых, при&nbsp;помощи такого запроса проблематично инстанцировать сущность с&nbsp;полностью инициализированным многоязычным атрибутом. Либо мы&nbsp;должны добавить <code>LEFT JOIN</code> для&nbsp;всех локалей, список которых нужно знать заранее, либо отказаться от&nbsp;использования атрибута типа <code>MultiCulturalString</code>, заменив на&nbsp;<code>String</code> и&nbsp;уменьшив число покрываемых сценариев. Еще один вариант&nbsp;— поддержать ленивую загрузку значений для&nbsp;различных локалей внутри многоязычной строки. Каждая из&nbsp;альтернатив имеет право на&nbsp;жизнь с&nbsp;учетом конкретных требований к&nbsp;продукту.

В-третьих, мы&nbsp;собираемся поддержать работу с&nbsp;многоязычными атрибутами в&nbsp;существующих ORM. Но&nbsp;нам вряд ли&nbsp;удастся найти такую точку расширения, чтобы добавить <code>JOIN</code> в&nbsp;SQL-запрос, при&nbsp;этом оставаясь в&nbsp;рамках простого LINQ-запроса:

<code-csharp>var result =  GetRepository<Product>()
    .Where(p => p.Name.ToString(enUS) == productName)
    .SingleOrDefault();</code-csharp>

Соединения с&nbsp;таблицей <code>t_product_localizable</code> можно заменить на&nbsp;подзапросы, но&nbsp;это&nbsp;принципиально ничего не&nbsp;меняет.

Весьма любопытный результат, не&nbsp;правда&nbsp;ли? Зато требование локализуемости выполняется.

==== Выводы ====

Как мы&nbsp;и&nbsp;ожидали, найти серебряную пулю среди рассмотренных вариантов не&nbsp;удалось. В&nbsp;каждом из&nbsp;них в&nbsp;большей или&nbsp;меньшей степени нарушается одно или&nbsp;несколько требований. Однако это не&nbsp;повод ничего не&nbsp;делать. Нам необходимо принять компромиссное решение, выбрать золотую середину.

Наиболее взвешенным и&nbsp;перспективным мы&nbsp;посчитали вариант одноколоночного сериализованного хранения. Поэтому в&nbsp;следующем разделе предлагаем рассмотреть особенности реализаций этого варианта для&nbsp;связок [http://nhibernate.info/ NHibernate]&nbsp;+ [http://www.oracle.com/technetwork/database/enterprise-edition/overview/index.html Oracle Database] и&nbsp;[https://docs.microsoft.com/en-us/ef/#pivot=efcore Entity Framework Core]&nbsp;+ [https://www.microsoft.com/en-us/sql-server/developer-get-started/ SQL Server]. Сериализацию многоязычных атрибутов будем делать в&nbsp;XML, а&nbsp;для&nbsp;доступа к&nbsp;локализованным значениям из&nbsp;БД — использовать средства СУБД.

== Расширяем ORM ==

Итак, мы предпримем попытку поддержать работу с&nbsp;сущностями, содержащими атрибут типа <code>MultiCulturalString</code>, а&nbsp;также запрос поиска таких сущностей по&nbsp;локализованному значению атрибута.

Вопрос поиска многоязычного атрибута по&nbsp;всем локалям мы рассматривать не&nbsp;будем, предоставив это&nbsp;заинтересованному читателю.

В&nbsp;реализации мы&nbsp;исходим из&nbsp;следующих принципов:
* Сущности описываются классами POCO (в&nbsp;Java&nbsp;— POJO).
* Сущности отделены от&nbsp;маппинга на&nbsp;объекты БД, в&nbsp;том числе от&nbsp;преобразований в&nbsp;формат&nbsp;БД и&nbsp;обратно.
* В&nbsp;запросах по&nbsp;возможности применяем «родное» API многоязычной строки. Таким образом получим прозрачное использование одного API и&nbsp;на&nbsp;клиенте, и&nbsp;на сервере.
* Деление на&nbsp;сборки должно быть мелким для&nbsp;лучшего разделения ответственностей, контроля зависимостей и&nbsp;переиспользования.

Приведем диаграмму зависимостей с&nbsp;мелким делением на&nbsp;сборки.

[[File:Иофе_код_4.png||600px|center]]

Сериализовывать значения многоязычной строки мы&nbsp;будем в&nbsp;XML. В&nbsp;.NET удачно разделены ответственности за&nbsp;содержание сериализованных данных (<code>ISerializable</code>, <code>ISerializationSurrogate</code>) и&nbsp;конечное сериализованное представление (<code>IFormatter</code>). И&nbsp;если первую ответственность вполне логично возложить на&nbsp;сам сериализуемый объект, то&nbsp;вторая зависит от&nbsp;использования. Поэтому для&nbsp;форматирования применим найденный на&nbsp;просторах интернета <code>XmlFormatter</code>: <code>IFormatter</code>, использующий <code>ISerializable</code>-возможности объектов.

=== NHibernate + Oracle Database ===

NHibernate, пожалуй, уже давно наиболее функциональный ORM под&nbsp;.NET. Вместе с&nbsp;тем он содержит противоречивые наслоения, возникшие на&nbsp;разных этапах его развития. Сейчас версии выходят крайне редко, контрибьюторов осталось мало. Некоторые давно ожидаемые исправления дефектов, видимо, не&nbsp;выйдут никогда.

Чтобы загрузить и&nbsp;сохранить значения многоязычной строки, нам необходимо реализовать <code>IUserType</code>, в&nbsp;котором и использовать упомянутый <code>XmlFormatter</code>.

Многоязычная строка в&nbsp;XML выглядит довольно очевидно.

<code-xml><?xml version="1.0" encoding="UTF-8"?>
<MultiCulturalString xsi:type="MultiCulturalString" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://custis.ru/i18n">
  <ru>Шоколад Алина</ru>
  <en>Chocolate Alina</en>
</MultiCulturalString></code-xml>

«Сердце» функции доступа к&nbsp;локализованным значениям McsGetString использует XQuery.

<code-sql>SELECT XMLCast(
  XMLQuery('declare namespace i18n="http://custis.ru/i18n"; for $mcs_locale in $mcs/i18n:MultiCulturalString/* where $mcs_locale/name() = $locale return $mcs_locale/text()'
    PASSING a_mcs AS "mcs", a_locale AS "locale" RETURNING CONTENT)
  AS VARCHAR2(4000 CHAR))
INTO l_value
FROM dual;</code-sql>


Чтобы использовать эту функцию в&nbsp;[http://nhibernate.info/doc/nhibernate-reference/queryhql.html HQL], достаточно добавить реализацию <code>ISQLFunction</code> в&nbsp;конфигурацию NHibernate. Но&nbsp;кроме того, мы&nbsp;хотим, чтобы обращение в&nbsp;LINQ-to-Database к&nbsp;перегрузкам <code>MultiCulturalString.ToString()</code> превращалось в&nbsp;вызов функции <code>McsGetString</code>. Впрочем, и&nbsp;для&nbsp;этого в&nbsp;NHibernate есть точка расширения: достаточно реализовать <code>IHqlGeneratorForMethod</code> и&nbsp;также зарегистрировать реализацию в конфигурации. Сама реализация <code>IHqlGeneratorForMethod</code> ожидаемо преобразует одно дерево выражений в&nbsp;другое.

Вот, собственно говоря, и&nbsp;все. Неужели мы молодцы, а&nbsp;с&nbsp;NHibernate все так беспроблемно? Увы, нет!

Вот такой простой тест не&nbsp;пройдет. 

<code-csharp>[Test]
public void TestNh2500()

{
    using (var session = SessionFactory.OpenSession())
    {
        var product = new Product
        {
            Code = ProductCode,
            Name = new MultiCulturalString(ru, ProductNameRu)
                .SetLocalizedString(en, ProductNameEn)
        };

        session.Save(product);
    }

    using (var session = SessionFactory.OpenSession())
    {
        var product = session.AsQueryable<Product>()
            .SingleOrDefault(p => p.Name.ToString(zhCHS)) == ProductNameEn);

        Assert.IsNotNull(product);
        Assert.AreEqual(ProductCode, product.Code);
    }

    using (var session = SessionFactory.OpenSession())
    {
        var product = session.AsQueryable<Product>()
            .SingleOrDefault(p => p.Name.ToString(ruRU)) == ProductNameEn);

        // The next line throws AssertionException
        Assert.IsNull(product);
    }
}</code-csharp>

Для обоих запросов будет сгенерирован одинаковый SQL:

<code-sql>
    select
        product0_.id_product as id1_0_,
        product0_.code as code0_,
        product0_.name as name0_ 
    from
        t_product product0_ 
    where
        McsGetString(product0_.name, 'zh-CHS', 'zh-CHS,zh-Hans,zh,en')=:p0;</code-sql>

Все дело в&nbsp;дефекте [https://nhibernate.jira.com/browse/NH-2500 NH-2500]: LINQ-запросы даже разных сессий кэшируются на&nbsp;уровне фабрики сессий и&nbsp;переиспользуются, несмотря на&nbsp;различные значения параметров запроса. Хотя баг уже шесть лет как критичный, исправление войдет только в&nbsp;будущую версию 5.1. А пока можно выпустить fork NHibernate. Если вам понадобится править какие-то другие дефекты NHibernate, низкая динамика продукта делает риски «протухания» ваших правок невысокими.

=== Entity Framework Core + SQL Server ===

Не&nbsp;так давно вышел [https://docs.microsoft.com/en-us/ef/core/what-is-new/ EF Core 2.0], и&nbsp;дальнейшее развитие именно за&nbsp;этой кроссплатформенной ветвью. Для&nbsp;наших примеров мы выбрали его, а&nbsp;не&nbsp;[https://docs.microsoft.com/en-us/ef/ef6/ EF 6], так&nbsp;как&nbsp;надеемся на&nbsp;скорое решение описанных ниже проблем.

К&nbsp;сожалению, в&nbsp;EF&nbsp;Core мы не&nbsp;можем реализовать поддержку пользовательского типа, в&nbsp;том числе <code>MultiCulturalString</code>. Но&nbsp;уже в&nbsp;версии фреймворка 2.1 появится такая возможность (см.&nbsp;[https://github.com/aspnet/EntityFrameworkCore/issues/242 issue #242]).

А пока что создадим прокси-класс для&nbsp;нашего товара со&nbsp;строковым атрибутом RawName.

<code-csharp>public class Product
{
    public virtual long Id { get; protected set; }
    public virtual String Code { get; set; }
    public virtual MultiCulturalString Name { get; set; }
}

public class ProductProxy : Product
{
    public override MultiCulturalString Name
    {
        get => base.Name;
        set
        {
            _rawName = ConvertToStoredValue(value);
            base.Name = value;
        }
    }

    public virtual String RawName
    {
        get => _rawName;
        set
        {
            base.Name = ParseStoredValue(value);
            _rawName = value;
        }
    }
    private String _rawName;

    ... 
}</code-csharp>

Именно прокси-класс будет участвовать в&nbsp;нашем <code>DbContext</code>. Как вы&nbsp;догадались, атрибут <code>Name</code> в&nbsp;маппинге участвовать не&nbsp;будет вовсе. Ну&nbsp;и&nbsp;конечно же, читателю хотелось бы&nbsp;используемый в&nbsp;маппинге атрибут <code>RawName</code> сделать <code>protected</code>, благо ORM-у это не&nbsp;мешает. Но&nbsp;не&nbsp;торопитесь!

Уже знакомый нам запрос 

<code-csharp>var result = GetRepository<ProductProxy>()
    .Where(p => p.Name.ToString(enUS) == productName)
    .SingleOrDefault();</code-csharp>

заработает в&nbsp;EF без&nbsp;дополнительных усилий с&nbsp;нашей стороны. Но&nbsp;только на&nbsp;клиенте! Ведь атрибут <code>Name</code> никак не&nbsp;маппится на&nbsp;БД. 

Большое подспорье, что EF позволяет получать предупреждения о&nbsp;клиентском выполнении части запроса либо запрещать его при&nbsp;помощи <code>DbContextOptionsBuilder.ConfigureWarnings</code>.

И&nbsp;даже после того, как будет сделан [https://github.com/aspnet/EntityFrameworkCore/issues/242 issue #242], мы можем использовать только статические функции для&nbsp;маппинга на&nbsp;функции БД. Использовать экземплярную функцию <code>ToString</code> не&nbsp;получится (см.&nbsp;[https://github.com/aspnet/EntityFrameworkCore/issues/9213 issue #9213]).

Возможным (пусть и&nbsp;временным) выходом для&nbsp;нас видится объявление методов-расширений <code>DbUserDefinedMethods.McsGetString(this String mcs, ...)</code>, по&nbsp;сигнатурам совпадающих с&nbsp;многочисленными перегрузками <code>MultiCulturalString.ToString</code>, без&nbsp;учета первого параметра <code>this</code>. Запросы будут иметь несколько искусственный вид:

<source lang="csharp">var result = GetRepository<ProductProxy>()
    .Where(p => p.RawName.McsGetString(enUS) == productName)
    .SingleOrDefault();</source>

Такие методы-расширения регистрируются в&nbsp;построителе модели, и&nbsp;задается преобразование из&nbsp;одного дерева выражений в&nbsp;другое, реализация которого практически не&nbsp;отличается от&nbsp;реализации <code>IHqlGeneratorForMethod</code> для&nbsp;NHibernate.

Вдобавок в&nbsp;EF вычислимость выражения анализируется на&nbsp;серверной стороне без&nbsp;учета преобразования зарегистрированной функции. Поэтому перегрузки <code>DbUserDefinedMethods.McsGetString</code>, содержащие неизвестные ORM типы <code>CultureInfo</code> и&nbsp;<code>IResourceFallbackProcess</code>, будут всегда вычисляться на&nbsp;клиенте.

Альтернатива всем перечисленным «костылям» в&nbsp;EF есть&nbsp;— это написание собственного провайдера. Тогда можно поддержать и&nbsp;любые типы, и&nbsp;необходимые экземплярные функции. Но&nbsp;с&nbsp;точки зрения поддержки, синхронизации с&nbsp;провайдером-оригиналом, который активно развивается, такое архитектурное решение выглядит слабым. Поэтому будем надеяться на хорошую динамику новой ветви развития EF.

== Заключение ==

Мы рассмотрели возможный сценарий использования и&nbsp;реализации поддержки многоязычных атрибутов. В&nbsp;то&nbsp;же время для&nbsp;некоторых простых сценариев использования многоязычных атрибутов достаточно в&nbsp;сущности декларировать только строковый атрибут, а&nbsp;для&nbsp;переключения между локализациями&nbsp;— вводить специальные методы вида <code>static String InLocale(this String mcs, CultureInfo culture, ...)</code>.

Недостаток рассмотренного варианта одноколоночного сериализованного хранения&nbsp;— в&nbsp;частности, больший трафик между клиентом и&nbsp;сервером и&nbsp;более высокое потребление памяти. 

Тем&nbsp;не&nbsp;менее поддержка многоязычных атрибутов и&nbsp;запросов с&nbsp;ними со&nbsp;стороны ORM позволяет получить полное, однородное и&nbsp;прозрачное для&nbsp;разработчиков решение. С&nbsp;нашей точки зрения, это неоспоримое преимущество описанного подхода.


[[Категория:Владислав Иофе (Статьи)]]
[[Категория:Хабрахабр (Публикации)]]
[[Категория:2018 год (Статьи)]]
[[Категория:CustisWikiToLib]]