WCF vs ASP .Net Web API


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 - це, мабуть, простота розробки, але це означає присідання, якщо це в кінцевому підсумку є серйозним обмеженням дизайну в дорозі.


15
Я вважаю назву цього питання трохи оманливою. Заголовок - "MVC 4 проти 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-адрес діяльності (вважайте це ресурсом, що самоописується)


6
Це дуже добре записувати. Найкращий, який я коли-небудь бачив. Але я зараз більше розгублений, ніж будь-коли. WebApi додає так багато, але неможливість викрити іншу кінцеву точку здається дуже обмежуючою. Якщо у вас був клієнт, який може використовувати мило, вони тепер будуть змушені будувати дію та аналізувати результат вручну, коли мило могло створити для них весь контекст. Ви також заблокуєте їх із більш досконалої функції мила, такої як надійний сеанс та кислотна транзакція ... зітхання.
Алвін

2
@Alwyn - Я вважаю, що всі згадані вами факти є істинними, і тому не повинні вас бентежити, а скоріше допомагати приймати рішення - Web API має свої переваги, але якщо ваш сервіс потребує впливу багатьох кінцевих точок, включаючи інші протоколи, або у вас є гостра потреба у функції автоматичного генерування клієнта або вдосконалених функцій мила - це може бути врахування, чому віддати перевагу WCF над Web API
BornToCode

@BornToCode: Код клієнта можна автоматично генерувати за допомогою WebAPI. Ви можете створити файл swags json за допомогою коду WebAPI. Цей файл json може бути використаний генератором коду, таким як swagger-codegen для створення коду клієнта на великій кількості цільових мов.
ненавмисно залишив порожнім

@unintentionallyleftblank - IMHO Це все-таки більш "зручно" для автоматичного генерування клієнтського коду через WCF, ніж Web 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, все це лише зміна конфігурації на відміну від коду + розгортання + QA + решта. То як Mvc Web Api краще?
Алвін

1
Якщо вам вже комфортно працювати з WCF, ви можете продовжити цей шлях. Окрім того, що я згадав, є деякі внутрішні покращення щодо REST у веб-API WCF (у мене немає списку перед собою), але я можу працювати, і я б не витрачав тижнів на рефакторинг, якщо у вас є тони робочі служби, особливо оскільки є трохи зрушення парадигми в мисленні. Для подальшої роботи я б розглядав веб-API WCF. Але я вже досить довго працюю з веб-API WCF, тому я можу бути упередженим.
Григорій А Бімер

0

Використовуйте WCF для сайтів intranet / B2B n Веб-API для B2C / C2C / Інтернет-сайтів ... SOAP / XML все ще є стандартом для внутрішньопідприємницької комунікації.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.