Один большой веб-сервис или много небольших?
Я создаю ряд методов для обеспечения функциональности многим различным веб-приложениям, методы в основном добираются, некоторые данные из SQL выполняют некоторые операции на нем и затем пасуют назад его к вызывающему приложению. Они должны быть реализованы через веб-сервисы.
Таким образом, мой вопрос - то, что является за и против между созданием одного значительного веб-сервиса с большим количеством методов или деления методов в логические группы и затрагиванием каждого из них в их собственный веб-сервис. Я думаю, что будет много последующих методов, реализованных после первой версии так независимо от того, что я делаю должно быть легко удобным в сопровождении.
Если это оказывает какое-либо влияние на ответы, я использую.Net 3.5, C# и не могу использовать WCF в данный момент.
4 ответа
Один большой
Плюсы:
- Нет необходимости поддерживать много ссылок на службы.
- Может ли быть проще найти то, что вы ищете, и получить обзор.
Минусы:
- Если вы когда-нибудь обновите 1 подпись, клиентам нужно будет добавить эту огромную (?) ссылку и перечитать WSDL.
- Сложнее делегировать работу, если присутствует много клиентов.
Много мелких
Плюсы:
Легче в обслуживании. Одно изменение в сигнатуре - небольшое изменение для клиентов.
Легче использовать разные хосты.
Минусы:
- Может легко превратиться в беспорядок.
Мой совет - взгляните на пакеты логики ваши услуги. Вероятно, клиенты будут пользоваться частью ваших услуг или всеми ими? Есть ли случаи, когда им нужно будет использовать половину услуги №1 и половину услуги №2? Попытайтесь выяснить, каковы распространенные сценарии,
Нам пришлось принять такое же решение несколько лет назад. Мы использовали очень детальный подход. Он нам очень хорошо послужил. Это позволило нам превратить веб-сервисы в своего рода API. Это не было нашим первоначальным намерением,
Некоторая пища для размышлений: Гранулярность хороша для большего контроля, но с ней связано снижение производительности. Если вы сделаете слишком детализированным, вы можете получить API, который потребует многократных сетевых циклов, чтобы делать что-нибудь нетривиальное. Таким образом, при разработке сервиса я хотел бы иметь в виду круговой обход сети и задержку. Если служба должна быть потенциально расположена в глобальной сети, я бы воздержался от создания «болтливого» интерфейса и выбрал методы, которые возвращают больше данных.
Например, я предпочитаю извлекать всего пользователя плюс ] их историю заказов, вместо одного отдельного вызова для данных пользователя и другого отдельного вызова для истории заказов, если большую часть времени вызывающий будет требовать и пользователя, и историю заказов.
Преимущество разделения их на отдельные службы заключается в том, что если вы начнете сталкиваться с проблемами производительности, вы всегда можете переместить отдельные службы на отдельные серверы.
Преимущество хранения их вместе на одном сервере. большая услуга заключается в том, что определенный код (например, чтение информации о конфигурации из файла) будет одинаковым для всех служб, и вы можете повторно использовать код, если он все в одной службе (вы также можете поместить свой повторно используемый код в отдельная библиотека классов).
Вы можете привести аргументы в любом случае. У меня есть два самых больших вопроса: 1) Связаны ли услуги? Есть ли смысл сгруппировать их вместе или вы просто группируете их для удобства? Если они связаны между собой, возможно, имеет смысл держать их вместе.
2) Какую нагрузку вы ожидаете? Можете ли вы реально ожидать, что один сервер справится с нагрузкой всех сервисов в течение следующих двух лет? Если нет, может быть, лучше сейчас же их разбить.