Вопрос: кто-нибудь занимался таким (сабж.)? Нужно: в базе есть 2 поля (NAME_EN, NAME_RU). В модели хочется иметь одно поле NAME, под которое подсовывалось соотв. поле из базы в зависимости от текущей локали.
Спасибо заранее за ответы.
</farsight>
Re: [Entity Framework 4.0] - подмена маппинга в runtime.
Здравствуйте, Farsight, Вы писали:
F>Нужно: в базе есть 2 поля (NAME_EN, NAME_RU). В модели хочется иметь одно поле NAME, под которое подсовывалось соотв. поле из базы в F>зависимости от текущей локали.
На сервере приложений локаль английская. Он загрузил из базы NAME_EN и отдал объект клиенту.
На клиенте локаль русская. Он ожидает получить NAME == "Иван", получает NAME == "John".
Привязывать бизнес-логику сервера к локали клиентов?
IMHO, это задача presentation layer на клиенте.
Отдайте объект с двумя свойствами NAME_RU и NAME_EN, а он пусть сам решает, какое из свойств отобразить.
Re[2]: [Entity Framework 4.0] - подмена маппинга в runtime.
Здравствуйте, HowardLovekraft, Вы писали:
HL>Здравствуйте, Farsight, Вы писали:
F>>Нужно: в базе есть 2 поля (NAME_EN, NAME_RU). В модели хочется иметь одно поле NAME, под которое подсовывалось соотв. поле из базы в F>зависимости от текущей локали.
HL>На сервере приложений локаль английская. Он загрузил из базы NAME_EN и отдал объект клиенту. HL>На клиенте локаль русская. Он ожидает получить NAME == "Иван", получает NAME == "John".
Клиент сообщает серверу свою локаль и получает NAME == "Иван", все довольны. Кстати, о существовании сервера ТС пока ничего говорил.
HL>Привязывать бизнес-логику сервера к локали клиентов?
Выбор локализованных строк это уже бизнес-логика? Что такого страшного случится если сервер будет получать и использовать локаль клиента?
HL>IMHO, это задача presentation layer на клиенте. HL>Отдайте объект с двумя свойствами NAME_RU и NAME_EN, а он пусть сам решает, какое из свойств отобразить.
Если будет больше 2-х языков тоже всё на клиент передавать?
Re[3]: [Entity Framework 4.0] - подмена маппинга в runtime.
Здравствуйте, k.o., Вы писали:
KO>Кстати, о существовании сервера ТС пока ничего говорил
Даже если у ТС не n-tier приложение, у него все равно есть слой бизнес-логики. KO>Выбор локализованных строк это уже бизнес-логика?
Читайте, пожалуйста, внимательнее.
Я сказал, что привязывать бизнес-логику сервера (в данном случае, кусок бизнес-логики — это загрузка объекта из базы) к локали клиента, по-моему, не хорошо. KO>Что такого страшного случится если сервер будет получать и использовать локаль клиента
Смотря в каком случае.
Для метода вида GetObject(Id) получается различный результат при одинаковом Id.
Следовательно, для тестирования слоя бизнес-логики вам придется перебрать все возможные локали. Оно надо?
Пусть этим занимаются разработчики presentation, потому что им это и так придется делать. KO>Если будет больше 2-х языков тоже всё на клиент передавать?
Если будет больше двух языков, будет отношение 1-* и отсутствие NAME_XX в самом объекте.
Re[4]: [Entity Framework 4.0] - подмена маппинга в runtime.
Здравствуйте, HowardLovekraft, Вы писали:
HL>Если будет больше двух языков, будет отношение 1-* и отсутствие NAME_XX в самом объекте.
Вот! Как Вы это делаете с точки зрения модели?
</farsight>
Re[4]: [Entity Framework 4.0] - подмена маппинга в runtime.
Здравствуйте, HowardLovekraft, Вы писали:
HL>Здравствуйте, k.o., Вы писали:
KO>>Кстати, о существовании сервера ТС пока ничего говорил HL>Даже если у ТС не n-tier приложение, у него все равно есть слой бизнес-логики.
В этом случае, по крайней мере, локаль будет одна что на "сервере", что на "клиенте".
KO>>Выбор локализованных строк это уже бизнес-логика? HL>Читайте, пожалуйста, внимательнее.
можно и на ты.
HL>Я сказал, что привязывать бизнес-логику сервера (в данном случае, кусок бизнес-логики — это загрузка объекта из базы) к локали клиента, по-моему, не хорошо.
Мне показалось, что если бизнес-логика не будет этим (загрузкой локализованных строк) заниматься, то и привязки не будет. И меня всё ещё удивляет, что "загрузка объекта из базы" это часть бизнес логики.
KO>>Что такого страшного случится если сервер будет получать и использовать локаль клиента HL>Смотря в каком случае. HL>Для метода вида GetObject(Id) получается различный результат при одинаковом Id.
скорее уж что-то вроде GetObject(Id, LocaledId), впрочем, мне трудно обсуждать поведение сферических методов в вакууме.
HL>Следовательно, для тестирования слоя бизнес-логики вам придется перебрать все возможные локали. Оно надо?
А все возможные Id тоже надо перебирать? А то мало-ли. Хотя, опять-таки, трудно обсуждать тестирование сферической бизнес-логики в вакууме.
HL>Пусть этим занимаются разработчики presentation, потому что им это и так придется делать. KO>>Если будет больше 2-х языков тоже всё на клиент передавать? HL>Если будет больше двух языков, будет отношение 1-* и отсутствие NAME_XX в самом объекте.
Да кто ж его знает как оно будет. Я бы и для 2-х языков, скорее всего, не стал бы помещать NAME_XX в сам объект. В любом случае, это мало относится к тому, что же должен возвращать сервер и должен-ли он использовать для обработки запросов локаль клиента. В самом деле, ты же не можешь серьёзно предлагать менять взаимодействие клиента и сервера только из-за добавления новых локалей?
Re[5]: [Entity Framework 4.0] - подмена маппинга в runtime.
Здравствуйте, Farsight, Вы писали:
F>Здравствуйте, HowardLovekraft, Вы писали:
HL>>Если будет больше двух языков, будет отношение 1-* и отсутствие NAME_XX в самом объекте. F>Вот! Как Вы это делаете с точки зрения модели?
Ну, например, таблица Names с записями вида |внешний ключ — ID объекта|ID локали|Name|.
Re[5]: [Entity Framework 4.0] - подмена маппинга в runtime.
Здравствуйте, Farsight, Вы писали:
F>Вот! Как Вы это делаете с точки зрения модели?
Заведите в модели ассоциацию "1 объект — * имен" и храните локализованные имена отдельно. У объекта появится коллекция:
public class SomeObject
{
public int Id { ... }
// more properties...public ObservableCollection<ObjectName> LocalizedNames { ... }
}
public class ObjectName
{
public int Id { ... }
public int LocaleId { ... }
public string Value { ... }
// more properties...
}
Загружайте в коллекцию те локализованные имена, которые необходимы. Либо вообще запрашивайте их отдельно.
Ну и в базе это — две таблицы вместо одной.
Re[5]: [Entity Framework 4.0] - подмена маппинга в runtime.
Здравствуйте, k.o., Вы писали:
KO>А все возможные Id тоже надо перебирать? А то мало-ли
Разные Id и разный результат — это нормально.
Один и тот же Id и разный результат — это не нормально.
Я не знаю, как объяснить понятнее.
KO>ты же не можешь серьёзно предлагать менять взаимодействие клиента и сервера только из-за добавления новых локалей?
Я как раз предлагаю так не делать.
Re[5]: [Entity Framework 4.0] - подмена маппинга в runtime.
Здравствуйте, k.o., Вы писали:
KO>В этом случае, по крайней мере, локаль будет одна что на "сервере", что на "клиенте".
Опять же, в общем случае, нет.
См. Thread.CurrentCulture и Thread.CurrentUICulture.
Re[6]: [Entity Framework 4.0] - подмена маппинга в runtime.
Здравствуйте, HowardLovekraft, Вы писали:
HL>Здравствуйте, k.o., Вы писали:
KO>>А все возможные Id тоже надо перебирать? А то мало-ли HL>Разные Id и разный результат — это нормально. HL>Один и тот же Id и разный результат — это не нормально.
HL>Я не знаю, как объяснить понятнее.
разные Id и разные LocaleId — разный результат. Всё-таки, мы либо добавляем локаль к запросу либо нет, если добавляем, то говорить, что у нас разные результаты для одного и того же запроса — неправильно.
KO>>ты же не можешь серьёзно предлагать менять взаимодействие клиента и сервера только из-за добавления новых локалей? HL>Я как раз предлагаю так не делать.
HL>>Отдайте объект с двумя свойствами NAME_RU и NAME_EN, а он пусть сам решает, какое из свойств отобразить.
KO>Если будет больше 2-х языков тоже всё на клиент передавать?
HL>Если будет больше двух языков, будет отношение 1-* и отсутствие NAME_XX в самом объекте.
Единственная расшифровка твоего ответа, которая приходит мне в голову, подразумевает изменение взаимодействия клиента и сервера. Поэтому я пытаюсь уточнить, что же ты имел в виду на самом деле.
Re[6]: [Entity Framework 4.0] - подмена маппинга в runtime.
Здравствуйте, HowardLovekraft, Вы писали:
HL>Здравствуйте, Farsight, Вы писали:
F>>Вот! Как Вы это делаете с точки зрения модели? HL>Заведите в модели ассоциацию "1 объект — * имен" и храните локализованные имена отдельно. У объекта появится коллекция: HL>
HL>public class SomeObject
HL>{
HL> public int Id { ... }
HL> // more properties...
HL> public ObservableCollection<ObjectName> LocalizedNames { ... }
HL>}
HL>public class ObjectName
HL>{
HL> public int Id { ... }
HL> public int LocaleId { ... }
HL> public string Value { ... }
HL> // more properties...
HL>}
HL>
HL>Загружайте в коллекцию те локализованные имена, которые необходимы. Либо вообще запрашивайте их отдельно. HL>Ну и в базе это — две таблицы вместо одной.
Да, так уже делал. Но 200 сущностей. Грустно стало в самом начале.
Что такого страшного случится если сервер будет получать и использовать локаль клиента?
