Як мені керувати технічною дискусією щодо WCF проти Web API?

Зараз я керую командою, що складається з 15 розробників, і ми зупинилися на виборі технології, коли команда розбита на дві абсолютно протилежні команди, обговорюючи питання використання WCF проти Web API.

Команда A, яка підтримує використання Web API, висуває такі причини:

1. Web API - це лише сучасний спосіб написання сервісів ( Wikipedia )
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 відсотків) нам можуть знадобитися розподілені транзакції.

Що мені робити зараз? Як мені керувати цією дискусією конструктивно?

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

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

Якщо припустити, що обидві сторони в усіх своїх аргументах на 100% вірні, які з них мають значення?

Моделі WCF не є POCO через [DataContract] та [DataMember] та ці атрибути

Вам все одно? Ви плануєте робити щось, що вимагає POCO?

WCF підтримує розподілені транзакції

Знову це щось, що ви збираєтеся використати і потрібно будувати, якщо у вас його немає, тому що ви пішли іншим шляхом?

В основному дістатися до серця одного з них:

• Пропонує все необхідне (Якщо жодна з них не пропонує все необхідне, що змушує вас виконати найменший обсяг роботи).
• Пропонує найменшу кількість сміття, яке ви не збираєтеся вживати, але все одно доведеться миритися.

Будь-який аргумент, висунутий на шляху до того, що вам потрібно досягти, не має значення і не повинен враховувати ваше рішення, маючи певну кімнату для розмивання для розгляду майбутнього розширення.

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

Як менеджер, ви повинні попросити своїх товаришів по команді пам’ятати про принцип Ягні . Це допоможе скоротити перелік причин, висунутих обома командами.

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

Замість того, щоб занурюватися в розподілену транзакцію, вам слід скористатися роботою з компенсацією .

Останнє, що слід врахувати, - це крива навчання. Залежно від терміну виконання вашого проекту, як менеджер, ви повинні мати можливість вирішити, нормально починати вивчення нової технології чи ні.

Якщо у вас є багато часу на марнотратство, то вирушайте на якийсь день інновацій, де Команда A і B матимуть день, щоб скласти доказ концепцій, заснованих на одних і тих же вимогах.

До речі, хлопцеві, який каже, що " моделі WCF не є POCO, через [DataContract] & [DataMember] та ці атрибути ", скажіть йому, що POCO в основному мають бути доменними об'єктами і що це не найкраща практика викривати ваш доменний об'єкт для будь-якого виду клієнтів, для чого призначений DTO.

Що мені робити зараз? Як мені керувати цією дискусією конструктивно?

По-перше, тримайте подалі суб'єктивність. В аргументах вашої команди WebAPI я вважаю, що "Web API - це просто сучасний спосіб" *, "моделі WCF не є POCO, через ці атрибути" і "SOAP не настільки читабельний і зручний, як JSON", досить виправданий, якщо не очевидний неправильний , і не допоможе прийняти рішення.

Отже, що робити: вирішіть, що ви хочете зробити зі своєю службою (послугами) , а потім виберіть техніку, яка відповідає цій цілі та її ремонтопридатності та розширюваності з найменшим болем. Це можна зробити, просто вивчивши, чи підтримується якийсь даний аспект рамкою, яку слід використовувати.

Цікавий матеріал для читання:

• Mvc 4 проти Wcf Web Api
• Веб-API WCF або ASP.NET? Мої два центи на цю тему
• WebAPI чи WCF?

*: зауважте, для цього ви посилаєтесь на Вікіпедію, де цитування: " Веб-програми Web 2.0 відійшли від орієнтованої на сервіс архітектури (SOA) з веб-службами на основі SOAP до більш згуртованих колекцій RESTful веб-ресурсів" . Це приклад використання для використання вашої послуги з веб-сторінки. Це також можна легко зробити за допомогою WCF, використовуючи WebHttpBinding. Це не говорить "Використовуйте для цього WebAPI" .

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

Управління командою осторонь, ви не обираєте один за іншим. Потрібно переглянути мету кожної веб-служби та використовувати відповідну технологію для конкретної частини програми. Це як заборона процедур зберігання, коли команда використовує структуру сутності.

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

Потім ви пишете ці 5 ~ 10% веб-сервісів у WCF. Якщо послугу потрібно посилати внутрішньо в інших проектах, дискусій немає. Перевага можливості імпорту WCF-контракту для створення клієнтського проксі НЕ відкрито для обговорення. Це забезпечує повну інтеграцію, ефективність та безпеку типу на абсолютно новий рівень.

Ви пишете, що потрібно використовувати для публічних запитів api (можливо) / Ajax запитів у веб-api Asp.net.

Якщо це лише певний сторінок Ajax для виклику, ви можете просто використовувати Asp.Net MVC.

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

Аналогічна дискусія в нашій команді була пару місяців тому. Для нас вирішальним фактором було те, як ми створимо та впровадимо кожну технологію. Оскільки ми вже будували додаток MVC і використовували Knockout.js для прив'язки даних, ми ефективно використовували MVVM з контролерами, просто API для даних.

Це дозволило нам класифікувати наше використання технологій у цьому проекті наступним чином:

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

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

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

Це був би найбільш розумний підхід. Досить поширеним є те, що послуги WCF та WebApi в одному веб-додатку, де обидва служать різним цілям.

Просто для виправлення кількох аргументів:

Моделі WCF не є POCO через [DataContract] та [DataMember] та ці атрибути

У багатьох випадках моделі WCF працюють без атрибутів datacontract / datamember.

SOAP не такий читабельний і зручний як JSON

Це неправда, але веб-сервіси WCF зазвичай мають звичайний XML, а не роздутий SOAP. Це , безумовно , є читаним.

Один аргумент для WCF: якщо є WSDL, у багатьох технологіях є безліч інструментів, які можуть створювати проксі-сервери з метаданих. З іншого боку, схема JSON ще не все широко підтримується.

Чому б не піти на лінію з послугами WCF Data? приємні запити в стилі OData / webapi та зручність використання з використанням повноважень WCF, а також можливість повернутись JSONпросто чудово. Також Wcf не так вже й погано, якщо у вас є хороший автоматичний код хостингу wcf, наприклад:

https://github.com/ImaginaryDevelopment/MvcOdata

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

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

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

Прийшов час викласти ці послуги віддаленим клієнтам, ви можете вибрати наймодніший каркас з полиці і написати тонкі обгортки на універсальному рівні обслуговування.

Чорт, якщо ваш "справжній" сервісний рівень зроблений добре, ви навіть можете спробувати кілька обгортків з мінімальними витратами.

Це все-таки догматична відповідь. На практиці ви можете вибрати найпростіший інструмент з полиці для полегшення ранніх і частих тестів на інтеграцію - але все ж обмежте свою залежність від цього і ставитесь до нього строго як до просто тонкого комунікаційного шару над реальними послугами.

Якщо ви скористаєтесь цим підходом, ви, мабуть, виявите, що ви вибрали найпростіший інструмент, який слід використати спочатку, і ніхто не буде метушитися , оскільки команда знає, що зможе впровадити більш складний або модний інструмент або рамку пізніше, якщо потрібно , з мінімальними зусиллями.

Отже, я зараз стикаюся з тим самим вибором, я запитав себе, який підмножини функцій WCF використовує наша команда на даний момент. Чи використовуємо ми різні протоколи? Ні. Чи використовуємо ми підтримку транзакцій? Ні (хоча ми використовуємо власні можливі механізми узгодженості). Ми використовуємо дуплекс? Немає.

Чому ми хотіли б використовувати веб-API? Легша інтеграція інтерфейсу (видаляє наявний додатковий рівень обслуговування), SignalR для виштовхування відповіді клієнтам, кешування для GET.

Можливо, можна знайти й інші причини :) Крім того, причини залишатися з WCF.

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

У будь-якому разі, якщо у вас є час, тоді вкладайте його в навчання та вдосконалення бази знань, але не за рахунок потреби бізнесу та продуктивності компанії.

Я б запитав, яку модель взаємодії вам потрібно підтримувати? Чи бажаний зовнішній інтерфейс більше нагадує RPC або REST? На мій досвід, це зазвичай десь між, але в основному тим чи іншим.

Ви споживаєте власні послуги для інших проектів у .Net? Це, мабуть, єдине найбільш показове питання, яке ви можете задати. WCF має перевагу в тому, що він може абстрагувати ваші інтерфейси в окрему бібліотеку класів і бути в змозі скласти і ввести інженеру свого клієнта. Як доповнення до цього, ви можете змонтувати проект на базі WCF як із кінцевими точками JSON, так і з SOAP / WSDL. Я це зробив. WCF також пропонує кращі гарантії щодо ваших визначених інтерфейсів.

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

Загалом, я б запропонував написати простий документ API, в якому зазначено, як ви будете подавати дані та як ви хочете відповісти для структури одного об'єкта запиту. Напишіть свій тестовий випадок найбільш універсальним способом і документуйте його як такий. Я б рекомендував просту заяву про завивку. Потім кілька ваших членів реалізують це за допомогою WCF та за допомогою Web API. Потім подивіться, хто виграє.

Особисто, незважаючи на те, що я робив кілька порівняно великих проектів та реалізацій з WCF, я насправді схиляюся до найпростішої реалізації, яка, на мій погляд, є насправді прямим WCF з використанням результатів JSON та деякої переоцінки поведінки в Global.asax.cs для боротьби з умовами помилок. Якщо документація API включає висловлювання завитків, і ви можете користуватися усіма функціоналами свого API за допомогою прикладів curl, клієнтам стає набагато простіше реалізувати будь-якою мовою, яка підтримує веб-інтерфейси. Це дійсно там, коли WCF починає падати. Маючи чітко визначений API з агностичною документацією, краще, ніж мати структури з автоматизованим інструментальним обладнанням при роботі з іноземними системами. Виступаючи як споживач тих систем з інших платформ.

Крім того, це реалізувати свого клієнта двома різними мовами. Зробіть клієнта в C #, а також зробіть його в Node.js або Python і подивіться, наскільки вони насправді підходять. Саме ця вправа допоможе вам витрусити вільні кінці у вашому API.