WCF против веб-API ASP .Net

93

Каковы плюсы и минусы использования каждой технологии?

WCF Web Api теперь объединен с Asp.net Веб-API Asp.net теперь поддерживает самостоятельный хостинг.

Я все еще представляю, что если я хочу предоставить несколько схем протоколов для одной и той же операции, я все равно буду склоняться к WCF, или может ли конечная точка Mvc сделать это тоже?

Также новый веб-интерфейс Asp.Net предоставляет доступ к Wsdl? Если нет, как клиент узнает, какая операция ему доступна?

Возможно, лучшая особенность Mvc - это привязка моделей. Насколько надежен эквивалент WCF?

Так может ли кто-нибудь сказать мне, какие преимущества дает веб-API Asp.net? WCF кажется в подавляющем большинстве более мощным / масштабируемым выбором, imo. Единственное, что Mvc Web Api имеет по сравнению с моделью WCF, это, вероятно, простота разработки, но это означает приседание, если в конечном итоге это станет серьезным ограничением дизайна в будущем.

wcf asp.net-mvc-4 asp.net-web-api Alwyn
источник
15
Я считаю, что название этого вопроса немного вводит в заблуждение. Заголовок - «MVC 4 vs Wcf Web Api», но, похоже, вопрос больше касается WCF и ASP .Net Web API. Судя по названию, я подумал, что сравнивается стандартная структура MVC 4 (контроллеры, модели, представления) и платформа ASP .Net Web API. Кто-нибудь еще находит это название вводящим в заблуждение?
BruceHill

Ответы:

72

Во-первых, я предлагаю вам прочитать мой пост на эту тему: http://blogs.microsoft.co.il/blogs/idof/archive/2012/03/05/wcf-or-asp-net-web-apis-my- два цента на предмет.aspx

Что касается вашего вопроса WSDL - поскольку WebApi не использует SOAP, он не требует WSDL и не экспортирует его. Вы можете использовать Hypermedia для возврата ресурсов со списком возможных URL-адресов действий (думайте об этом как о ресурсе с самоописанием)

IdoFlatow
источник
6
Это очень-очень хорошая запись. Лучшее, что я когда-либо видел. Но сейчас я сбит с толку больше, чем когда-либо. WebApi добавляет так много, но невозможность раскрыть другую конечную точку кажется очень ограничивающей. Если у вас был клиент, который может использовать мыло, он теперь будет вынужден создать действие и проанализировать результат вручную, когда мыло могло бы сгенерировать для них весь контекст. Вы также заблокируете их для более продвинутой функции Soap, такой как надежный сеанс и кислотная транзакция ... вздох.
Alwyn
2
@Alwyn - Я думаю, что все упомянутые вами факты верны и поэтому не должны вас смущать, а скорее помочь вам принять решение - веб-API имеет свои преимущества, но если ваша служба должна быть доступна с нескольких конечных точек, включая другие протоколы, или у вас острая потребность в функции автоматической генерации клиента или расширенных функциях мыла - это может быть соображением, почему предпочесть WCF веб-API
BornToCode
@BornToCode: клиентский код может быть автоматически сгенерирован с помощью WebAPI. Вы можете создать json-файл swagger, используя код WebAPI. Затем этот json-файл может использоваться генератором кода, например swagger-codegen, для создания клиентского кода на большом количестве целевых языков.
непреднамеренно оставлено пустым
@unintentionallyleftblank - IMHO Автоматическая генерация клиентского кода через WCF по-прежнему «удобнее», чем через веб-API.
BornToCode
15

Выбор зависит от того, чем мы хотим заниматься.

  1. Веб-API ASP.NET - это платформа для создания служб, не основанных на SOAP, только через HTTP, поэтому с помощью этой платформы не существует других транспортных протоколов.
  2. WCF / Windows Communication Foundation - это платформа для обмена сообщениями на основе SOAP - здесь мы используем множество транспортных протоколов: HTTP, TCP, именованные каналы, MSMQ и т. Д.

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

Младший Майе
источник
2
Без обид, но HTTP - это просто протокол прикладного уровня . Он не имеет внутренних ограничений на то, какие протоколы транспортного уровня могут использоваться.
smwikipedia
8

Веб-API WCF в основном ориентирован на реализации REST. Если вы настраиваете реализацию REST, стандартные биты WCF немного мешают. Если вы настраиваете службы RESTful, вам будет удобнее пользоваться веб-API WCF. Если вы настраиваете службы SOAP, тогда веб-API WCF не ваш лучший друг, и вам лучше использовать WCF для своих служб.

Грегори А Бимер
источник
2
Да, конфиги - это боль, но это единовременная плата за настройку. Как только вы это сделаете, вы можете практически скопировать и вставить поведение / конечную точку в другую службу. В большинстве случаев вы просто помечаете новые операции тегами WebGet. С другой стороны, если вы когда-нибудь получите клиент, который захочет использовать Soap + Wsdl, это всего лишь изменение конфигурации, а не код + развертывание + контроль качества + все остальное. Так чем же Mvc Web Api лучше?
Alwyn
1
Если вы уже знакомы с WCF, вы можете продолжить этот путь. В дополнение к тому, что я упомянул, есть некоторые внутренние улучшения REST в веб-API WCF (у меня нет списка перед собой), но любой из них может работать, и я бы не стал тратить недели на рефакторинг, если у вас есть тонны рабочие услуги, особенно поскольку в мышлении произошла небольшая смена парадигмы. Однако для будущей работы я бы рассмотрел WCF Web API. Но я уже довольно давно работаю с веб-API WCF, поэтому могу быть предвзятым.
Gregory A Beamer
0

Используйте WCF для интранет / B2B-сайтов n Web API для B2C / C2C / интернет-сайтов ... SOAP / XML по-прежнему является стандартом для внутрикорпоративной коммуникации, и он никуда не денется !!!

A_Var
источник