Jak zarządzać debatą techniczną dotyczącą WCF vs. Web API?

Zarządzam zespołem złożonym z około 15 programistów i utknęliśmy w punkcie, w którym wybieramy technologię, w której zespół jest podzielony na dwa całkowicie przeciwne zespoły, debatując nad użyciem WCF vs. Web API.

Zespół A, który obsługuje korzystanie z interfejsu API sieci Web, przedstawia następujące powody:

1. Web API to po prostu nowoczesny sposób pisania usług ( Wikipedia )
2. WCF to narzut na HTTP. Jest to rozwiązanie dla TCP, Net Pipe i innych protokołów
3. Modele WCF nie są POCO z powodu [DataContract] i [DataMember] i tych atrybutów
4. SOAP nie jest tak czytelny i przydatny jak JSON
5. SOAP to narzut dla sieci w porównaniu do JSON (transport przez HTTP)
6. Brak przeciążenia metody

Zespół B, który obsługuje korzystanie z WCF, mówi:

1. WCF obsługuje wiele protokołów (poprzez konfigurację)
2. WCF obsługuje transakcje rozproszone
3. Istnieje wiele dobrych przykładów i przykładów sukcesu dla WCF (podczas gdy Web API jest jeszcze młody)
4. Dupleks jest doskonały do ​​komunikacji dwukierunkowej

Ta debata trwa i nie wiem, co teraz zrobić. Osobiście uważam, że powinniśmy używać narzędzia tylko do jego właściwego miejsca użytkowania . Innymi słowy, lepiej byłoby użyć interfejsu API sieci Web, jeśli chcemy udostępnić usługę przez HTTP, ale użyć WCF, jeśli chodzi o TCP i dupleks.

Przeszukując Internet, nie możemy uzyskać solidnego wyniku. Istnieje wiele postów wspierających WCF, ale wręcz przeciwnie, ludzie również narzekają na to. Wiem, że charakter tego pytania może wydawać się dyskusyjny, ale potrzebujemy dobrych wskazówek, aby podjąć decyzję. Utknęliśmy w miejscu, gdzie wyborze technologii przez przypadek może uczynić nam żałować później. Chcemy wybierać z otwartymi oczami.

Używamy głównie do internetu i udostępniamy nasze usługi przez HTTP. W niektórych przypadkach (powiedzmy od 5 do 10 procent) możemy potrzebować transakcji rozproszonych.

Co mam teraz zrobić? Jak zarządzać tą debatą w konstruktywny sposób?

Kiedy obie strony mają dobre argumenty, a opinie w tej sprawie są zbyt mocne, aby dojść do konsensusu, jako menedżer musisz podjąć decyzję i zakończyć debatę. W przeciwnym razie po prostu zakręci się w kółko i jeszcze bardziej wzmocni pozycje wszystkich uczestników. Im dłużej zwlekasz, tym trudniej będzie „przegranej” stronie przyznać się do porażki i produktywnie pracować z wynikiem.

Zapisz wszystkie argumenty, doceń ich znaczenie dla projektu, a następnie podejmij decyzję. Kiedy nie możesz, rzuć monetą. Twój projekt prawdopodobnie zakończy się sukcesem przy użyciu dowolnej technologii, a marnowanie cennego czasu na niepotrzebne debaty będzie po prostu kosztowało niepotrzebne pieniądze.

Zakładając, że obie strony są w 100% poprawne we wszystkich swoich argumentach, które mają znaczenie?

Modele WCF nie są POCO z powodu [DataContract] i [DataMember] i tych atrybutów

Czy ci zależy? Czy planujesz zrobić coś, co wymaga POCO?

WCF obsługuje transakcje rozproszone

Znów jest to coś, co zamierzasz wykorzystać i musisz zbudować, jeśli go nie masz, ponieważ wybrałeś inną ścieżkę?

Zasadniczo przejdź do sedna tego:

• Oferuje wszystko, czego potrzebujesz (jeśli nie oferuje wszystkiego, czego potrzebujesz, co sprawia, że ​​musisz wykonać najmniej pracy).
• Oferuje najmniej śmieci, z których nie będziesz korzystać, ale i tak musisz się z nimi pogodzić.

Każdy argument, który nie jest na drodze do tego, co musisz osiągnąć, jest nieistotny i nie powinien uwzględniać twojej decyzji, z pewną przestrzenią do rozważenia przyszłej ekspansji.

Włóż moje dwa centy.

Jako menedżer powinieneś poprosić członków swojej drużyny, aby pamiętali o zasadzie Yagni . Pomoże to zmniejszyć listę powodów przedstawionych przez oba Zespoły.

Używamy głównie do internetu i udostępniamy nasze usługi przez HTTP. W niektórych przypadkach (powiedzmy od 5 do 10 procent) możemy potrzebować transakcji rozproszonych.

Zamiast nurkowania w rozproszonej transakcji, powinieneś rozważyć pracę z rekompensatą .

Ostatnią rzeczą, którą należy wziąć pod uwagę, jest krzywa uczenia się. W zależności od terminu realizacji projektu, jako menedżer, powinieneś być w stanie zdecydować, czy możesz zacząć uczyć się nowej technologii, czy nie.

Jeśli masz dużo czasu do stracenia, wybierz się na Dzień Innowacji, w którym Drużyna A i B mieliby dzień na przedstawienie dowodu koncepcji opartego na tych samych wymaganiach.

Nawiasem mówiąc, facetowi, który mówi: „ Modele WCF nie są POCO, z powodu [DataContract] i [DataMember] i tych atrybutów ”, powiedz mu, że POCO mają zasadniczo być podmiotami domeny i że nie jest najlepszą praktyką ujawnianie Twój obiekt domeny dla dowolnego rodzaju klientów, po to są DTO.

Co mam teraz zrobić? Jak zarządzać tą debatą w konstruktywny sposób?

Po pierwsze, trzymaj się z dala od podmiotowości. W argumentach twojego zespołu WebAPI stwierdzam, że „Web API to po prostu nowoczesny sposób” *, „Modele WCF nie są POCO, ze względu na te atrybuty”, a „SOAP nie jest tak czytelny i przydatny jak JSON”, dość przekonany, jeśli nie po prostu zły i nie pomoże w podjęciu decyzji.

Co więc zrobić: zdecyduj, co chcesz zrobić ze swoimi usługami , a następnie wybierz technikę, która uwzględnia ten cel oraz jego łatwość utrzymania i rozszerzania przy najmniejszym bólu. Możesz to zrobić, po prostu sprawdzając, czy dany aspekt jest obsługiwany przez środowisko do użycia.

Ciekawy materiał do czytania:

• Mvc 4 vs. Wcf Web Api
• WCF czy ASP.NET Web API? Moje dwa centy na ten temat
• WebAPI czy WCF?

*: zauważ, że odwołujesz się do Wikipedii, gdzie cytat brzmi: „ Aplikacje internetowe Web 2.0 odeszły od architektury zorientowanej na usługi (SOA) opartej na usługach SOAP w kierunku bardziej spójnych kolekcji zasobów sieci RESTful” . Jest to przykład zastosowania, gdy usługa ma być pobierana ze strony internetowej. Można to również łatwo zrobić za pomocą WCF, używając WebHttpBinding. Nie jest napisane „Użyj do tego WebAPI” .

Jeśli to pytanie wykracza poza „jak zarządzać dyskusją” : skorzystałbym z WCF, jeśli usługi mają być używane przez klientów niebędących klientami sieci, ponieważ ich metadane pozwalają na zadziwiająco łatwe generowanie silnie typowanych klientów.

Pomijając zarządzanie zespołem, nie wybierasz jednego nad drugim. Musisz spojrzeć na cel każdej usługi sieciowej i użyć odpowiedniej technologii dla określonej części aplikacji. To tak, jakby zakazać procedur sklepowych, gdy zespół korzysta ze szkieletu encji.

Używamy głównie do internetu i udostępniamy nasze usługi przez HTTP. W niektórych przypadkach (powiedzmy od 5 do 10 procent) możemy potrzebować transakcji rozproszonych.

Następnie piszesz te 5 ~ 10% usług sieciowych w WCF. Jeśli usługa ma się odnosić wewnętrznie w innych projektach, nie ma debaty. Zaletą możliwości importowania umowy WCF w celu utworzenia serwera proxy klienta NIE jest otwarta do dyskusji. Zabiera całą integrację, wydajność i bezpieczeństwo typu na zupełnie nowy poziom.

W interfejsie internetowym Asp.net piszesz, co ma być używane do publicznych żądań interfejsu API (być może) / Ajax.

Jeśli jest to wywołanie aukcji specyficzne dla strony, możesz po prostu użyć Asp.Net MVC.

Nie wybieraj, obejmij je wszystkie. Interfejsy sieciowe WCF i Asp.net służą różnym celom. Nikt nie mówi, że nie możesz mieć jabłka i pomarańczy zarówno w sałatce owocowej. Próba wybrania jednego z nich i zepchnięcia go w każdy scenariusz to po prostu lenistwo.

Nasz zespół miał podobną dyskusję kilka miesięcy temu. Decydujący dla nas czynnik sprowadził się do tego, jak stworzymy i wdrożymy każdą technologię. Ponieważ budowaliśmy już aplikację MVC i korzystaliśmy z Knockout.js do wiązania danych, skutecznie korzystaliśmy z MVVM, a kontrolery były tylko interfejsem API dla danych.

Pozwoliło nam to sklasyfikować wykorzystanie technologii w tym projekcie w następujący sposób:

• Interfejs API sieci Web byłby używany jako nasz interfejs API dla wywołań knockout i Ajax, co czyni je naszymi poleceniami dla wzorca MVVM. Nasza logika biznesowa dla aplikacji internetowej jest zamknięta za tą warstwą poprzez szereg klas, repozytoriów i fabryk.
• WCF jest następnie wykorzystywany w naszym magazynie danych, ujawniając dane z naszej bazy danych nie tylko dla tej witryny, ale także dla każdej innej witryny lub usługi, która wykorzystała ujawnione dane.

Chociaż może to nie być popularna ani hiper-techniczna odpowiedź, określenie, czego potrzebujesz najpierw i jak lub czy technologia pomoże, pomogło zespołowi zdecydować, której technologii użyć.

Innymi słowy, lepiej byłoby użyć interfejsu API sieci Web, jeśli chcemy udostępnić usługę przez HTTP, ale użyć WCF, jeśli chodzi o TCP i Duplex.

To byłoby najbardziej rozsądne podejście. Dość powszechne jest posiadanie usług WCF i WebApi w tej samej aplikacji internetowej, gdzie obie służą innym celom.

Aby poprawić kilka argumentów:

Modele WCF nie są POCO z powodu [DataContract] i [DataMember] i tych atrybutów

W wielu przypadkach modele WCF działają bez atrybutów datacontract / datamember.

SOAP nie jest tak czytelny i przydatny jak JSON

Tak nie jest, ale usługi sieciowe WCF zwykle zawierają zwykły XML, a nie rozdęty SOAP. To zdecydowanie jest czytelne.

Jeden argument dla WCF: jeśli dostępny jest WSDL, istnieje mnóstwo narzędzi w prawie wszystkich technologiach, które mogą tworzyć proxy z metadanych. Z drugiej strony schemat JSON nie jest jeszcze powszechnie obsługiwany.

Dlaczego nie przejść linii usług WCF Data Services? ładne zapytania w stylu OData / webapi i użyteczność dzięki możliwościom WCF, a także możliwość zwrotu w JSONporządku. Również Wcf nie jest taki zły, jeśli masz ładny automatyczny kod hostingowy wcf, taki jak:

https://github.com/ImaginaryDevelopment/MvcOdata

Powiedziałbym, że wcale nie są daleko od siebie oddzielone, z wyjątkiem tego, że kiedy poszliśmy użyć WebApina przednim końcu i WCF data servicesna środkowej warstwie, WebApizwymiotowaliśmy na proste rzeczy, takie jak ciąg znaków lub ciągi pasujące do operatorów odata.

Dobry architekt opóźnia decyzje technologiczne, dopóki nie są absolutnie konieczne.

Innymi słowy, nie podejmuj decyzji, dopóki klient nie będzie musiał się połączyć. Możesz zbudować w pełni przetestowaną warstwę usług bez faktycznego nakładania na nią mechanizmu transportu / komunikacji. Ponad 95% pracy można wykonać „pod” adapterem, poza ramą.

Nadszedł czas, aby udostępnić te usługi zdalnym klientom, możesz wybrać najmodniejsze ramy z półki i pisać cienkie opakowania na uniwersalnej warstwie usług.

Do diabła, jeśli twoja „prawdziwa” warstwa usługi jest dobrze wykonana, możesz nawet wypróbować kilka opakowań przy minimalnym koszcie.

W każdym razie taka jest dogmatyczna odpowiedź. W praktyce , może chcesz wybrać najprostsze narzędzia z półki, aby ułatwić wczesne i częste testy integracyjne - ale nadal ograniczyć zależność od niego i leczyć go wyłącznie jako po prostu cienkiej warstwie komunikacyjnej nad rzeczywistych usług.

Jeśli zastosujesz to podejście, prawdopodobnie okaże się, że wybierasz najprostsze narzędzie, którego chcesz użyć na początku i nikt nie będzie się tym przejmował , ponieważ zespół wie, że może wdrożyć bardziej wyrafinowane lub modne narzędzie lub strukturę później, jeśli to konieczne , przy minimalnym wysiłku.

Dlatego jestem w obliczu takiego samego wyboru teraz, zadałem sobie pytanie, co jest podzbiór funkcji z WCF nasz zespół korzystających w tej chwili. Czy używamy różnych protokołów? Nie. Czy korzystamy z obsługi transakcji? Nie (chociaż korzystamy z niestandardowych mechanizmów spójności). Czy korzystamy z dupleksu? Nie.

Dlaczego chcielibyśmy korzystać z Web API? Łatwiejsza integracja interfejsu użytkownika (usuwa istniejącą już dodatkową warstwę usługi), SignalR do wypychania odpowiedzi do klientów, buforowania dla GET.

Być może można znaleźć inne powody :) Powody, dla których warto zostać w WCF.

Gdybym był na twoim miejscu, zacząłbym od sprawdzenia umiejętności twoich drużyn. Jeśli wszyscy w twoim zespole już znają WCF i tylko niewielki procent zna Web API, Twoja decyzja jest już podjęta.

Jeśli masz czas, zainwestuj go w naukę i ulepszanie bazy wiedzy, ale nie kosztem potrzeb biznesowych i produktywności firmy.

Chciałbym zapytać, jaki model interakcji potrzebujesz wesprzeć? Czy pożądany interfejs zewnętrzny bardziej przypomina RPC lub REST? Z mojego doświadczenia wynika, że ​​zwykle jest to gdzieś pomiędzy, ale głównie jedno lub drugie.

Czy korzystasz z własnych usług dla innych projektów w .Net? Jest to prawdopodobnie najbardziej odkrywcze pytanie, jakie możesz zadać. Zaletą WCF jest możliwość abstrakcyjnego tworzenia interfejsów w osobnej bibliotece klas oraz budowania i wstrzykiwania klienta. Jako rozszerzenie tego, możesz zamontować swój projekt oparty na WCF zarówno z punktami końcowymi JSON, jak i SOAP / WSDL, zrobiłem to. WCF zapewnia również lepszą ochronę zdefiniowanych interfejsów.

To powiedziawszy, jeśli oczekujesz, że ogólnie będziesz mieć klientów z innych platform XML, nie mówiąc już o SOAP, który ma wymierny narzut, wykraczający poza proste punkty końcowe JSON. Jeśli wybierzesz trasę JSON / Web API, będziesz musiał znacznie lepiej udokumentować interakcję z punktami końcowymi i interfejsem API.

Ogólnie sugerowałbym napisanie prostego dokumentu API, który określa, w jaki sposób prześlesz dane i jak chcesz uzyskać odpowiedź dla struktury obiektu pojedynczego żądania. Napisz swój przypadek testowy w najbardziej uniwersalny sposób i udokumentuj go jako taki. Poleciłbym proste stwierdzenie curl. Następnie poproś kilku członków, aby zaimplementowali to za pomocą WCF i Web API. Następnie sprawdź, które wygrane.

Osobiście, pomimo wykonania kilku stosunkowo dużych projektów i wdrożeń w WCF, faktycznie skłaniam się ku najprostszej implementacji, która moim zdaniem jest właściwie prostą WCF z wykorzystaniem wyników JSON i niektórych zachowań nadpisywania w Global.asax.cs do radzenia sobie z warunkami błędu. Jeśli dokumentacja interfejsu API zawiera instrukcje curl i możesz korzystać ze wszystkich funkcji interfejsu API z przykładami curl, klienci mogą znacznie łatwiej wdrożyć w dowolnym języku obsługującym interfejsy sieciowe. To właśnie tam WCF zaczyna upaść. Posiadanie dobrze zdefiniowanego API z dokumentacją agnostyczną jest lepsze niż posiadanie struktur z zautomatyzowanym oprzyrządowaniem w przypadku obcych systemów. Mówiąc jako konsument tych systemów z innych platform.

Poza tym należy wdrożyć klienta w dwóch różnych językach. Zrób klienta w C #, ale także zrób to w Node.js lub Python i zobacz, jak dobrze one pasują. Samo ćwiczenie pomoże ci wytrząsnąć luźne końce interfejsu API.