Silverlight в Соа как архитектура - PullRequest
1 голос
/ 23 марта 2011

Давайте рассмотрим небольшой случай, чтобы мне было легко объяснить мою дилемму.

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

  • StudentManagementService - Управление всеми данными учащихся
  • TestManagementServide - Для управления всеми тестами, такими как экзамен C # и прочее
  • StudentScoreService- Ведет оценку, какую оценку кто получил по тому или иному тесту

Так что вот тут-то и встает моя дилемма: я хочу построить клиент Silverlight.На мой взгляд, у меня есть 2 варианта общения с этими службами:

  1. Позвоните в эти службы напрямую из моего приложения Silverlight (из клиента)

  2. Позвоните в службу поддержки Silverlight Host / Home / owner и оттуда все эти услуги

Как я вижу, здесь есть некоторые преимущества и недостатки для обоих случаев

Дело1:

  • Каждый сервис должен поддерживать безопасность типа silverligth (имя пользователя / пароль в этом случае)
  • Каждый сервис должен иметь привязку типа Silverligt (это может привести к кодированиюдополнительные услуги)
  • Нет необходимости в дополнительном лейере, как в случае 2
  • Междоменная политика

Дело 2:

  • У вас есть leyer между вашими приложениями Silverlight, работающими как рутеры
  • У вас есть дополнительный leyer, который переводит данные silverlight в другие сервисы для оптимальной предварительной обработки, такой как net.tcp
  • Нет КрестаПолитика домена

Так что же думают другие?И можете ли вы говорить из опыта?

Thx

1 Ответ

3 голосов
/ 23 марта 2011

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

...