Где разместить языковые переводы в многоуровневой архитектуре

Question

Я создаю приложение со следующими слоями:

• слой веб-презентации
• Уровень бизнес-логики - BLL - вызывается из веб-интерфейса через веб-службы HTTP
• WindowsService - Runtime - вызывается из BLL через net.pipe

BLL также может быть вызван от третьей стороны для интеграции в системы других клиентов.

Допустим, есть ошибка проверки, которая происходит во время выполнения или даже в BLL. Куда лучше было бы поставить переводы:

1. в сообщении об исключении - означает что мы должны отправить UICulture от WEB слой на нижние слои
2. BLL и Runtime возвращают ошибку коды или пользовательские исключения получены типы и перевод выполняется в слое WEB UI
3. какой-то другой метод

Какова наилучшая практика поддержки нескольких языков в архитектурах SOA?

EDIT: Я, вероятно, должен использовать термин «уровни» вместо слоев.

• Уровень веб-интерфейса реализован в веб-формах ASP.NET и будет развернут на сервере A в IIS.
• BLL и среда выполнения будут развернуты на сервере B, но разделены границами процесса (BLL работает под рабочим процессом ASP.NET из-за служб WCF, а среда выполнения работает как отдельный процесс службы Windows).

Answer 1

Мой совет по вашим вопросам носит общий характер, поскольку я не знаю специфики платформы .NET, с которой вы работаете.

Из вашего вопроса я вижу две разные проблемы.

1. Уровень веб-презентации будет зависеть от языка. Для этого потребуются пользовательские CSS, шрифты, интервалы и даже пользовательский контент. Не обманывайте себя, что это не понадобится. Это одна из самых больших ошибок, которые люди делают изначально при интернационализации веб-приложений. Вам понадобится другой стиль для языка. Таким образом, если вы используете шаблонный подход, вы можете поместить большую часть вашего языкового контента прямо в языковой шаблон.

2. Судя по описанию вашей проблемы, вам также потребуется обрабатывать локализованные сообщения об ошибках. Существует два подхода, два из которых: у вас может быть языковой файл, который вы локализуете при возникновении ошибки, используя решение с использованием файла ресурсов. Другой подход заключается в том, чтобы ваши сообщения об ошибках использовали общий идентификатор и параметры, а другой слой мог перехватить сообщение и локализовать его. Я сам предпочитаю первое решение, так как оно проще.

Также помните, что если вы пишете свои сообщения об ошибках в файл журнала, то сообщения об ошибках на языке, который могут читать разработчики. Аналогично, для ошибок, отображаемых пользователям в графическом интерфейсе, вы захотите, чтобы пользователи могли идентифицировать ошибки для разработчиков, которые не говорят на языке пользователя. Это можно сделать с помощью цифр - я предпочитаю использовать короткие клавиши, такие как DATABASE_ERROR_BAD_QUERY.

Answer 2

Перевод должен обрабатываться уровнем представления, так как он относится к представлению. Чем больше контекста можно добавить к сообщению, тем лучше, и бизнес-логика может не знать о контексте, и не должно быть.

Подход, который я использовал, выглядит следующим образом:

• Бизнес-логика генерирует уникальные, определенные коды ошибок, которые можно использовать в качестве ключей в комплект ресурсов, чтобы получить переведенное сообщение.

• Уровень представления поддерживает текст пакет, содержащий весь код ошибки переводы отдельно от общий код уровня представления.

• Уровень представления зависит от
  и бизнес-логика и текст пакет.

• Сторонние клиенты бизнес-логики, такие как веб-сервис, можете включить текст пакет как зависимость, если они хотят стандартные переводы кодов ошибок. В противном случае они могут обработать ошибку коды, выдаваемые бизнес-логикой на свои.

Answer 3

В зависимости от структуры вашего приложения вам может потребоваться интернационализация в двух местах:

1) Само программное обеспечение. Меню, диалоги, сообщения, метки, отчеты и т. Д.

2) Контент. При работе на нескольких языках вашему приложению, вероятно, потребуется обрабатывать контент на нескольких языках.

Мне повезло в разделении инструментов управления и логики публикации на разных уровнях (пока).

Во-первых, рассмотрите возможность размещения логики управления и генерации языкового перевода (комплекты ресурсов и т. Д.) В бизнес-логике. Итак, для всех ваших переводов вам нужен способ быстрой синхронизации всех записей данных по мере их добавить в систему на всех языках от основного языка (английский), а затем заполнить и управлять ими. Поэтому, если вы используете, например, комплекты ресурсов, создайте файлы rb из базы данных для всех языков.

Во-вторых, публиковать логику языковых переводов на уровне представления. Это больше связано с представлением и форматированием. Вы неизбежно столкнетесь с проблемами локализации дат, времени, валют и т. Д., С которыми вы вполне можете справиться здесь. Вы можете или не можете создавать свою собственную библиотеку для публикации этих вещей как ограничивающих, или гибкость вашего языка программирования может или не может позволить.

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

Удачи!

Answer 4

Я не совсем уверен, как вы определяете веб-интерфейс. Если вы используете шаблон MVC, Controller будет иметь место, чтобы позаботиться об отображении верной языковой версии в пользовательском интерфейсе, тогда как сам текст будет находиться в слое View. Что я не понял, так это то, что играет роль контроллера в вашей архитектуре. Означает ли BLL только включение логики обработки и отсутствие связи между пользовательским интерфейсом и службами? Если это так, то, вероятно, слой веб-интерфейса будет содержать логику локализации.

Я бы также сказал, что это во многом зависит от технологии, которую вы используете в проекте. Например, ASP.NET имеет встроенную модель локализации, которую вы можете использовать. Я не говорю, что это должно служить примером, даже наоборот - ASP.NET нарушает разделение интересов. Но я думаю, что это проблема, которая будет иметь разные решения в разных моделях пользовательской архитектуры, как в вашем случае.