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

Question

я построить приложение со следующими слоями:

• WEB презентация слоя
• Business Logic Layer - BLL - вызывается из веб-интерфейса пользователя с помощью веб-служб HTTP
• WindowsService - Runtime - вызвано от BLL через net.pipe

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

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

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

Что является лучшей практики для supporti многоязычных языков в архитектурах SOA?

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

• Презентация слой содержит пакет текста , содержащий весь код ошибки переводов отдельно от кода общего представления слоя.

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

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

Answer 4

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

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

2) Содержание. Возможно, ваше приложение, работающее на нескольких языках, должно обрабатывать контент на нескольких языках.

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

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

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

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

Удачи!