Які відмінності між веб-сервісами WCF та ASMX?

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

Які відмінності між WCF та веб-сервісами? Коли кожен повинен бути використаний?

Кіт Елдер тут непогано порівнює ASMX з WCF . Перевір.

Ще одне порівняння ASMX і WCF можна знайти тут - я не на 100% згоден з усіма пунктами, але це може дати вам уявлення.

WCF в основному "ASMX на стереоїдах" - це може бути все, що міг ASMX - плюс багато іншого! .

ASMX:

• легко та просто записати та налаштувати
• доступний лише в IIS
• дзвонить лише з HTTP

WCF може бути:

• розміщена в IIS, сервісі Windows, додатку Winforms, консольному додатку - ви маєте повну свободу
• використовується з HTTP (REST та SOAP), TCP / IP, MSMQ та багатьма іншими протоколами

Якщо коротко: WCF тут, щоб замінити ASMX повністю.

Перевірте Центр розробників WCF на MSDN .

Оновлення: посилання здається мертвим - спробуйте: Що таке Фонд зв’язку Windows?

Веб-сервіси ASMX можуть викликати лише HTTP (традиційна веб-служба з .asmx). Хоча службу WCF або компонент WCF можна викликати будь-яким протоколом (наприклад, http, tcp тощо) та будь-яким типом транспорту.

По-друге, веб-сервіси ASMX не є гнучкими. Однак послуги WCF є гнучкими. Якщо ви робите нову версію послуги, вам потрібно просто виставити новий кінець. Тому послуги є спритними і це дуже практичний підхід, дивлячись на сучасні тенденції бізнесу.

Ми розробляємо WCF як договори, інтерфейс, операції та договори з даними. Як розробник ми більше зосереджені на послугах ділової логіки і не потрібно турбуватися про стек каналу. WCF - це єдиний API програмування для будь-якого виду послуг, тому ми створюємо службу та використовуємо інформацію про конфігурацію для налаштування механізму зв'язку, наприклад HTTP / TCP / MSMQ тощо

Це дуже давнє питання, але я не відчуваю, що переваги ASMX були належним чином зображені. Хоча не дуже гнучкі, веб-сервіси ASMX дуже прості у використанні та розумінні. Хоча WCF є більш гнучким, він також складніше встати і налаштувати.

Веб-сервіси ASMX готові встати і додати як посилання на веб-сервіс, як тільки ви додасте файл. (припустимо, що ваш проект будується)

Для простого робочого процесу розвитку create webservice-> run webservice-> add webservice reference, у веб-сервісі ASMX є дуже мало, що може піти не так, не так багато, що ви можете неправильно налаштувати, і це - його сила.

У відповідь на ті, хто стверджує, що WCF замінює ASMX, я відповів би, що WCF потрібно буде додати впорядкований режим конфігурації KISS, щоб повністю замінити ASMX.

Приклад web.config для веб-сервісу ASMX:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings />
  <system.web>
    <compilation targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" />
  </system.web>
</configuration>

WCF повністю замінює веб-сервіси ASMX. ASMX - це старий спосіб робити веб-сервіси, а WCF - це поточний спосіб робити веб-сервіси. Всі нові розробки веб-сервісів SOAP на клієнті або сервері повинні здійснюватися за допомогою WCF.

Проводиться багато розмов щодо простоти веб-служб asmx через WCF. Дозвольте мені уточнити кілька моментів.

• Це правда, що початківці розробники веб-служб почнуть легко працювати у веб-сервісах asmx. Visual Studio робить всю роботу для них і легко створює проект Hello World.
• Але якщо ви можете навчитися WCF (який, звичайно, не забирає багато часу), то ви можете зрозуміти, що WCF також досить простий, і ви можете легко рухатися вперед.
• Важливо пам’ятати, що зазначені складності у WCF насправді приписуються прекрасним рисам, які він приносить разом із собою. У конфігураційному файлі є всі адреси, прив'язки, контракти та кінцеві точки, послуги та клієнти. Краса - ваша логіка бізнесу відокремлена і підтримується безпечно. Завтра , якщо вам потрібно змінити зв'язування з BasicHttpBinding на NetTcpBinding ви можете легко створити прив'язки в файлі конфігурації і використовувати його. Таким чином, всі зміни, пов'язані з клієнтами, каналами зв’язку, прив’язками тощо, слід проводити в конфігурації, залишаючи бізнес-логіку безпечною та неушкодженою, що має справжній сенс.
• "Веб-сервіси" WCF - частина набагато більш широкого спектру віддаленого спілкування, що забезпечується через WCF. Ви отримаєте набагато більшу ступінь гнучкості та портативності, роблячи справи в WCF, ніж через традиційний ASMX, оскільки WCF створений з самого початку, щоб узагальнити всі різні інфраструктури розподіленого програмування, пропоновані Microsoft. Кінцеву точку в WCF можна зв’язувати так само легко через SOAP / XML, як і через TCP / бінарний файл, а змінити цей носій - це просто файл конфігураційного файла. Теоретично це зменшує кількість нового коду, необхідного під час перенесення або зміни потреб бізнесу, цілей тощо.
• Доступ до веб-сервісів можна отримати лише через HTTP, і він працює в умовах без громадянства, де WCF є гнучким, оскільки його послуги можуть розміщуватися в різних типах додатків. Ви можете розмістити свої сервіси WCF в консолі, службах Windows, IIS & WAS, які знову різні способи створення нових проектів у Visual Studio.
• ASMX старший за WCF, і все, що ASMX може зробити це може WCF (і більше). В основному, ви можете бачити WCF як намагається логічно згрупувати всі різні способи змусити два програми спілкуватися у світі Microsoft; ASMX був лише одним із цих багатьох способів, і тепер він згрупований під парасолькою WCF можливостей.
• Ви завжди хочете використовувати Visual Studio для NET 4.0 або 4.5, оскільки це полегшує життя під час створення служб WCF.
• Основна відмінність полягає в тому, що веб-сервіси використовують XmlSerializer. Але WCF використовує DataContractSerializer, який кращий за продуктивністю порівняно з XmlSerializer. Ось чому WCF працює краще, ніж інші колеги з технологій зв'язку від .NET, як-от asmx, .NET віддалення тощо.

Не варто забувати, що я був одним із тих хлопців, яким більше подобалися послуги asmx, ніж WCF, але в той час я не дуже добре знав послуги WCF та його можливості. Я злякався конфігурацій WCF. Але я наважився і спробував написати декілька власних служб WCF, і коли я дізнався більше про WCF, тепер я не маю жодних перешкод щодо WCF, і рекомендую їх усім і всім. Щасливого кодування !!!