Один большой веб-сервис или много маленьких?

Я создаю набор методов для предоставления функциональности нескольким различным веб-приложениям, методы в основном получают некоторые данные из SQL, выполняют некоторые операции над ним, а затем передают его обратно вызывающему приложению. Они должны быть реализованы через веб-сервисы.

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

Если это влияет на ответы, я использую .Net 3.5, C# и не могу использовать WCF на данный момент.

7
.net design web-services

4 ответов

одна большая
Плюсы:

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

плюсы:

  • если вы когда-нибудь обновите подпись 1, клиентам нужно будет добавить этот огромный (?) ссылка и перечитывание WSDL.
  • труднее делегировать работу, если много клиентов подарок.

много маленьких
Плюсы:

  • легче поддерживать. Одно изменение в подписи-это небольшое изменение для клиентов.

  • проще использовать разные хосты.

плюсы:

  • может легко вырасти в беспорядок.

мой совет-посмотреть на логические пакеты ваших услуг. Могут ли клиенты использовать часть ваши услуги или все? Есть ли случаи, когда им нужно будет использовать половину сервиса №1 и половину сервиса № 2? Попытайтесь выяснить, каковы общие сценарии, и спроектируйте свои службы так, чтобы им нужно было создать только один прокси-сервер для его работы.

4

некоторая пища для размышлений: гранулированный хорош для большего контроля, но у него есть связанный штраф за производительность. Если ты пойдешь слишком granular, вы можете получить API, который потребует нескольких сетевых поездок туда и обратно, чтобы сделать что-то нетривиальное. Таким образом, я бы держал сеть туда и обратно и латентность в виду при разработке сервиса. Если служба должна быть потенциально расположена через WAN, я бы воздержался от создания" болтливого " интерфейса и пошел на методы, которые возвращают больше данные.

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

5

нам пришлось принять такое же решение несколько лет назад. Мы пошли с очень тщательного подхода. Это нам очень помогло. Это позволило нам превратить веб-сервисы в своего рода API. Это не было нашим первоначальным намерением, но это сработало очень хорошо для нас.

Ренди

2

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

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

вы можете привести аргументы для любого случая. Два самых больших вопроса, которые у меня были бы: 1) связаны ли услуги? Имеет ли смысл группировать их вместе или вы просто группируете их вместе для удобства? Если они родственники, возможно, имеет смысл держать их вместе.

2) какую нагрузку вы ожидаете? Можете ли вы реально ожидать, что один сервер будет обрабатывать нагрузку на все службы в течение следующих нескольких лет? Если нет, то может быть лучше чтобы разлучить их сейчас.

2