Как мне управлять техническими дебатами по поводу WCF против Web API?


49

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

Команда A, которая поддерживает использование Web API, выдвигает следующие причины:

  1. Web API - это просто современный способ написания сервисов ( Википедия )
  2. WCF - это издержки для HTTP. Это решение для TCP, Net Pipes и других протоколов.
  3. Модели WCF не являются POCO из-за [DataContract] & [DataMember] и этих атрибутов
  4. SOAP не так удобен для чтения и удобен, как JSON
  5. SOAP - это нагрузка на сеть по сравнению с JSON (транспорт по HTTP)
  6. Нет перегрузки метода

Команда B, которая поддерживает использование WCF, говорит:

  1. WCF поддерживает несколько протоколов (через конфигурацию)
  2. WCF поддерживает распределенные транзакции
  3. Для WCF существует множество хороших примеров и историй успеха (хотя Web API еще молод)
  4. Дуплекс отлично подходит для двусторонней связи

Эта дискуссия продолжается, и я не знаю, что делать сейчас. Лично я думаю, что мы должны использовать инструмент только для его правильного места использования . Другими словами, нам лучше использовать Web API, если мы хотим предоставить сервис через HTTP, но использовать WCF, когда речь идет о TCP и Duplex.

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

Наше использование будет в основном для веба, и мы будем предоставлять наши сервисы через HTTP. В некоторых случаях (скажем, от 5 до 10 процентов) нам могут понадобиться распределенные транзакции.

Что мне теперь делать? Как мне вести эту дискуссию конструктивно?


11
Не забывайте, что веб-API не позволяет потребителям легко генерировать сервисный клиент, как это делает SOAP WSDL. Если у вас когда-либо будут только клиенты .NET, это не представляет особой проблемы, поскольку они могут совместно использовать объекты контракта, которые вы реализуете, но другим языковым клиентам потребуется вручную создавать свои объекты клиентов, если вы не используете SOAP.
Джимми Хоффа

10
также помните, что WCF может делать json довольно прилично в большинстве случаев
Bill

3
«3. Модели WCF не POCO», что просто неверно. Вам не нужно использовать какие-либо атрибуты, так как .NET 3.5 SP1.
Аллон Гуралнек

4
Этот вопрос, кажется, не по теме, потому что речь идет об управлении дискуссиями среди коллег, а не о разработке программного обеспечения.
GrandmasterB

3
Википедия определяет «современный способ написания сервисов»? Не уверен, насколько это полезно.
Фрэнк Хилман

Ответы:


38

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

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


3
Уважаемый @Philipp, спасибо за предложение монет . Но, как я уже сказал, я не хочу сожалеть об этом случайном решении. Хотя я считаю, что ловкость имеет значение, я также считаю, что хорошие решения тоже имеют значение.
Саид Нимати

5
@SaeedNeamati: Если после сбора и взвешивания всей информации ни одна технология не имеет явного преимущества, то подбрасывание монеты является наиболее честным способом принятия решения. Независимо от результата жеребьевки, это хорошее решение, потому что вы взвесили всю информацию.
Барт ван Инген Шенау

9
@SaeedNeamati: я полностью согласен с "подбросить монетку". Прямо сейчас вы находитесь в явном параличе анализа (ваши точные слова на этой вики-странице), что для ИМО более опасно, чем выбор решения, которое может быть не лучшим. Если у вас такое трудное решение, это означает, что даже другое, менее оптимальное решение не так уж плохо. И пока вы разрабатываете свое программное обеспечение модульным способом, вы должны иметь возможность оставить достаточно абстракции, чтобы вывести одну технологию и при необходимости внедрить другую, что в любом случае маловероятно.
ДХМ

2
@SaeedNeamati С точки зрения технологии, нет такого понятия, как «сожалеть» об этом решении. Вы всегда будете делать ошибки. Что более важно, так это уметь обнаруживать ошибки как можно скорее, открыто признавать их и менять решение в лучшую сторону.
Спящий Смит

4
Другие варианты: кулачный бой; поединок; Человек, который кричит громче всех, побеждает. Конечно, это лучше, чем подбрасывание монеты? :)
Фрэнк Хилман

13

Предполагая, что обе стороны на 100% верны во всех своих аргументах, какие из них имеют значение?

Модели WCF не являются POCO из-за [DataContract] & [DataMember] и этих атрибутов

Вы заботитесь? Вы планируете делать то, что требует POCO?

WCF поддерживает распределенные транзакции

Опять же, это то, что вы собираетесь использовать и нужно строить, если у вас его нет, потому что вы выбрали другой путь?

В основном добраться до сути которого:

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

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


1
Модели службы данных WCF являются POCO, единственным требованием является поле [имя] ID iirc.
Маслоу

11

Положите мои два цента.

Как менеджер, вы должны попросить своих товарищей по команде учитывать принцип Ягни . Это поможет сократить список причин, выдвинутых обеими командами.

Наше использование будет в основном для веба, и мы будем предоставлять наши сервисы через HTTP. В некоторых случаях (скажем, от 5 до 10 процентов) нам могут понадобиться распределенные транзакции.

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

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

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

Кстати, парню, который говорит, что « модели WCF не являются POCO, из-за [DataContract] & [DataMember] и этих атрибутов », скажите ему, что POCO обычно предназначены для доменных сущностей, и что это не лучший способ выставлять Ваш домен является объектом для любых клиентов, для этого нужны DTO.


+1 за то, что не выставлял доменные объекты в внешнем / внешнем контракте. Сделайте это как минимум 10 раз для дешевых побед, а в 9 из них рефакторинг из-за боли в наличии фиксированного договора связи и управлении сменой домена. +1 для распределенных транзакций, это очень злая вещь ..
user1496062

5

Что мне теперь делать? Как мне вести эту дискуссию конструктивно?

Во-первых, держите подальше субъективность. В аргументах вашей команды WebAPI я нахожу «Web API - это просто современный способ» *, «модели WCF не являются POCO из-за этих атрибутов», а «SOAP не так удобен для чтения и удобен, как JSON», довольно самоуверенный, если не совсем неправильный и не поможет принять решение.

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

Интересные материалы для чтения:

*: обратите внимание, что для этого вы обращаетесь к Википедии, где цитируется следующее: « Веб-приложения Web 2.0 отошли от сервис-ориентированной архитектуры (SOA) с веб-сервисами на основе SOAP в направлении более сплоченных коллекций веб-ресурсов RESTful» . Это пример использования, когда ваш сервис должен использоваться с веб-страницы. Это также легко можно сделать с помощью WCF, используя WebHttpBinding. Там не написано "Используйте WebAPI для этого" .

Если этот вопрос выходит за рамки «как управлять обсуждением» : я бы использовал WCF, если сервисы будут использоваться не-веб-клиентами, потому что его метаданные позволяют удивительно легко генерировать строго типизированные клиенты.


1
Не только это. « XYZ просто современный способ » является NULL-аргумент, который обычно читается как « у меня нет реальных аргументов, но это мой личный фаворит сезона. »
JensG

4

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

Наше использование будет в основном для веба, и мы будем предоставлять наши сервисы через HTTP. В некоторых случаях (скажем, от 5 до 10 процентов) нам могут понадобиться распределенные транзакции.

Затем вы пишете эти 5 ~ 10% веб-сервисов в WCF. Если на сервис нужно ссылаться изнутри в других проектах, споров нет. Преимущество возможности импорта контракта WCF для создания клиентского прокси НЕ открыто для обсуждения. Требуется полная интеграция, эффективность и безопасность типов на совершенно новый уровень.

Вы пишете, что будет использоваться для публичных запросов API (возможно) / Ajax в веб-интерфейсе Asp.net.

Если это просто вызов страницы ajax, вы можете просто использовать Asp.Net MVC.

Не выбирай, обними их всех. WCF и веб-API Asp.net служат различным целям. Никто не говорит, что вы не можете иметь яблоко и апельсин в своем фруктовом салате. Попытка выбрать один над другим и столкнуть его с каждым сценарием - просто лень.


4

Наша команда провела похожее обсуждение пару месяцев назад. Решающим фактором для нас стало то, как мы будем создавать и внедрять каждую технологию. Поскольку мы уже создавали приложение MVC и использовали Knockout.js для привязки данных, мы эффективно использовали MVVM, а контроллеры были просто API-интерфейсом для данных.

Это позволило нам классифицировать использование технологий в этом проекте следующим образом:

  • Веб-API будет использоваться в качестве нашего API для вызовов нокаута и Ajax, что делает их нашими командами для шаблона MVVM. Наша бизнес-логика для веб-приложения скрывается за этим уровнем через ряд классов, репозиториев и фабрик.
  • Затем WCF используется для нашего хранилища данных, предоставляя данные из нашей базы данных не только для этого веб-сайта, но и для любого другого сайта или службы, которые использовали данные.

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


как ваш слой WCF обрабатывает аутентификацию?
Маслоу

3

Другими словами, нам лучше использовать Web API, если мы хотим предоставить сервис через HTTP, но использовать WCF, когда речь идет о TCP и Duplex.

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

Просто чтобы исправить несколько аргументов:

Модели WCF не являются POCO из-за [DataContract] & [DataMember] и этих атрибутов

Во многих случаях модели WCF работают без атрибутов datacontract / datamember.

SOAP не так удобен для чтения и удобен, как JSON

Это не так, но веб-сервисы WCF обычно несут простой XML, а не раздутый SOAP. Это , безусловно , является читаемым.

Один аргумент в пользу WCF: если доступен WSDL, во многих технологиях есть тонны инструментов, которые могут создавать прокси из метаданных. С другой стороны, схема JSON еще не все широко поддерживается.


2

Почему бы не пойти по пути с WCF Data Services? хорошие запросы в стиле OData / webapi и удобство использования с возможностями WCF, а также возможность возврата JSONпросто отлично. Кроме того, Wcf не так уж плох, если у вас есть хороший автоматический код хостинга wcf, как показано ниже:

https://github.com/ImaginaryDevelopment/MvcOdata

Я бы сказал, что они совсем не далеки друг от друга, за исключением того, что, когда мы перешли к использованию WebApiна переднем конце и WCF data servicesна среднем уровне, мы WebApiстолкнулись с простыми вещами, такими как строка содержит операторы строки данных, соответствующие строке.


1

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

Другими словами, не принимайте решение, пока клиенту не понадобится подключиться. Вы можете создать полностью протестированный сервисный уровень без фактического наложения на него механизма транспорта / связи. 95% + работы можно выполнить «под» адаптером вне рамок.

Пришло время представить эти сервисы удаленным клиентам, вы можете выбрать самые современные фреймворки и написать тонкие обертки поверх универсального сервисного уровня.

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

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


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


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

0

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

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

Может быть, можно найти и другие причины :) А также причины остаться с WCF.


2
OP не спрашивает о WCF против Web API, OP спрашивает о том, как управлять внутренними, техническими дебатами, которые ведутся в его команде. Ваш ответ не попадает в более широкую часть вопроса.

0

Если бы я был на вашем месте, я бы начал с изучения способностей ваших команд. Если все в вашей команде уже знают WCF, и лишь небольшой процент знает Web API, то ваше решение уже принято за вас.

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


0

Я бы спросил, какую модель взаимодействия вам нужно поддерживать? Ваш внешний интерфейс больше напоминает RPC или REST? По моему опыту это обычно где-то между, но в основном одно или другое.

Вы используете свои собственные услуги для других проектов в .Net? Это, пожалуй, самый показательный вопрос, который вы можете задать. WCF имеет то преимущество, что может абстрагировать ваши интерфейсы в отдельную библиотеку классов и иметь возможность создавать и внедрять ваш клиент. В качестве дополнения к этому, вы можете смонтировать ваш проект на основе WCF как с конечными точками JSON, так и с SOAP / WSDL, я это сделал. WCF также предлагает лучшие гарантии против определенных вами интерфейсов.

Тем не менее, если вы ожидаете иметь клиентов с других платформ XML в целом, не говоря уже о том, что SOAP имеет измеримые издержки, превышающие возможности простых конечных точек JSON. Если вы пойдете по пути JSON / Web API, вам нужно будет намного лучше документировать, как взаимодействовать с вашими конечными точками и API.

В общем, я бы предложил написать простой документ API, в котором указано, как вы будете отправлять данные и как вы хотите получить ответ для структуры объекта с одним запросом. Напишите свой тестовый пример наиболее универсальным способом и запишите его как таковой. Я бы порекомендовал простое заявление curl. Затем попросите нескольких ваших участников реализовать это с помощью WCF и с помощью веб-API. Тогда посмотри, кто победит.

Лично, несмотря на то, что я выполнил несколько относительно крупных проектов и реализаций с WCF, я фактически склоняюсь к самой простой реализации, которая, на мой взгляд, на самом деле является прямой WCF с использованием результатов JSON и некоторым поведением переопределения в Global.asax.cs для работы с ошибочными условиями. Если документация API включает в себя операторы curl, и вы можете использовать все функциональные возможности своего API с примерами curl, клиенту будет намного проще реализоваться на любом языке, который поддерживает веб-интерфейсы. Это действительно, где WCF начинает падать. Наличие четко определенного API с независимой документацией лучше, чем наличие структур с автоматизированным инструментарием при работе с сторонними системами. Выступая в качестве потребителя этих систем с других платформ.

Помимо этого, реализуйте свой клиент на двух разных языках. Сделайте клиента в C #, но также сделайте один в Node.js или Python и посмотрите, насколько хорошо они подходят. Одно это упражнение поможет вам избавиться от слабых сторон в вашем API.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.