WCF Data Services (OData) Vs ASP.NET Web API

Istnieją obecnie inne istotne różnice między WebApi a WCF Data Services, o których nikt nigdy nie wspomina. Szkoda, że MS nie wyjdzie z dobrym artykułem porównującym te dwa.

OData + WCF Data Services w końcu zezwoliła Klientowi Aplikacje, aby były bardziej "ekspresyjne" podczas zapytań o Dane przez Internet. Wcześniej zawsze musieliśmy używać ASMX lub WCF do tworzenia sztywnych interfejsów API, które stają się nieporęczne i wymagają ciągłych zmian, gdy interfejs chce czegoś nieco innego. Aplikacja kliencka mogła określać tylko parametry, aby dyktować, jakie kryteria należy zwrócić. Albo zrób tak jak ja i "Serializuj" wyrażenia LINQ i przekaż je jako parametry i ponownie nawodnij do Expressions<Func<T,bool>> Na serwerze. Jest przyzwoity. Wykonałem zadanie, ale chcę użyć LINQ na kliencie i mieć go przetłumaczone przez Internet za pomocą REST, co jest dokładnie to, co OData pozwala i nie chcę korzystać z mojego własnego "hack" rozwiązania.

To jak odsłanianie "TRANSACT SQL" bez potrzeby ciągów połączeń DB. Wystarczy podać adres Url i whoala! Zacznij pytać. Oczywiście zarówno WebApi, jak i WCF Data Services obsługują uwierzytelnianie/autoryzację, dzięki czemu można kontrolować dostęp, dołączać dodatkowe instrukcje "gdzie" na podstawie ról lub innej konfiguracji danych. Wolałabym zrób to w warstwie mojego Web Api niż w SQL (jak budowanie widoków lub przechowywane proc). Teraz, gdy aplikacje mogą tworzyć zapytania samodzielnie, zobaczysz narzędzia do raportowania Ad-Hoc i BI, które zaczynają wykorzystywać OData i pozwalają użytkownikom definiować własne wyniki. Nie polegając na raportach statycznych, gdzie mają minimalną kontrolę.

Podczas tworzenia w Silverlight, Windows 8 Metro lub ASP.NET (MVC, WebForms, etc), można po prostu dodać "Service Reference" w Visual Studio do usługi danych WCF i szybko zacznij używać LINQ do zapytań o dane, a otrzymasz" kontekst danych "na kliencie, co oznacza, że śledzi zmiany i pozwala" przesłać " zmiany atomicznie z powrotem do serwera. Jest to bardzo podobne do usług RIA dla Silverlight. Użyłbym WCF Data Services zamiast RIA Services, ale wtedy nie obsługiwał Dataannotacji ani akcji, ale teraz tak :) WCF Data Services ma kolejną przewagę nad usługami RIA, czyli możliwość wykonywania "projekcji" z Klient. Może to pomóc w wydajności, okrywając, że nie chcę zwracać wszystkich właściwości z obiektu. Posiadanie "kontekstu danych" na kliencie jest świetne, gdy masz do czynienia z aplikacjami biznesowymi.

Tak więc WCF Data Services jest świetny, jeśli masz dane z relacjami, zwłaszcza jeśli używasz SQL Server i Entity Framework. Szybko będziesz w stanie ujawnić dane + akcje (wywołania operacji, tj. przepływy pracy, procesy w tle) nad resztą z bardzo małą ilością kodu. Dane WCF Usługi zostały zaktualizowane. Premiera nowej wersji. Sprawdź wszystkie nowe funkcje.

Minusem WCF Data Services jest" kontrola", którą tracisz nad stosem HTTP. Odkryłem największą wadę w metodach IQueryable<T>, które zwracają zbiory. W przeciwieństwie do usług RIA i WebApi, nie masz pełnego dostępu do rozwijania logiki w metodzie IQueryable. W usługach RIA i WebApi możesz napisać dowolny kod, o ile zwrócisz IQueryable<T>. W WCF Data Services dostajesz tylko dostęp do dodawania instrukcji "Where" przy użyciu metod przechwytujących Expression<Func<T,bool>>. To mnie rozczarowało. Nasza obecna aplikacja korzysta z usług RIA i uważam, że naprawdę potrzebujemy umiejętności kontrolowania logiki IQueryable. Mam nadzieję, że się mylę i coś mi umyka

A co z WebApi???

1. lubię kontrolę nad Http Request / Response
2. to łatwe do naśladowania (wykorzystanie wzorców MVC). Jestem pewien, że przyjdzie więcej narzędzi.

Jak na razie (z mojego zrozumienia), nie ma wsparcia "kontekstu danych" na kliencie (TJ Silverlight, ASP.NET Kod po stronie serwera, itp), Ponieważ WebApi nie jest tak naprawdę o modelach danych encji, jak WCF Data Services/OData. Może wystawiać kolekcje obiektów modelu za pomocą IQueryable/IEnumerable, ale nie ma "właściwości nawigacyjnych" klucza głównego/klucza obcego (tj. klient.Faktury) do użycia po załadowaniu encji na klienta, ponieważ nie ma "kontekstu danych", który ładuje je asynchronicznie( lub w jednym wywołaniu używając $expand) i zarządza zmianami. Nie masz Wygenerowanej kodowo" reprezentacji " modelu danych podmiotu na kliencie, tak jak w usługach RIA lub WCF Data Services. Nie mówię, że nie możesz/nie masz modeli w kliencie, które reprezentują Twoje dane, ale ręcznie wypełniasz dane i zarządzasz, które" faktury " mają być ustawione każdy "klient" po ich pobraniu przez Internet. To może być trudne, szczególnie z tymi wszystkimi sprawami asynchronicznymi. Nie wiesz, które Telefony wrócą pierwsze. Może to być trudne do wyjaśnienia, ale po prostu przeczytaj o "kontekście danych" w usługach RIA lub WCF Data Services. Tak więc w przypadku aplikacji biznesowych jest to dla mnie poważny problem. Opiera się to głównie na wydajności i łatwości konserwacji. Możesz przestarzale tworzyć aplikacje bez kontekstu danych. To tylko sprawia, że łatwiej, szczególnie w Silverlight, WPF, a teraz Windows 8 Metro. Posiadanie Bytów relacyjnych ładowanych do pamięci asynchronicznie i posiadanie dwóch wiązań jest naprawdę miłe.

Powiedziawszy to, czy oznacza to, że pewnego dnia WebApi może obsługiwać" kontekst danych " na kliencie? Myślę, że może. Ponadto, dzięki większej liczbie narzędzi, projekt Visual Studio może wygenerować wszystkie metody CRUD na podstawie schematu bazy danych (lub struktury podmiotu).

Poza tym, Wiem, że wspominam tylko o. NET do. NET Frameworków jeśli chodzi o pracę z WCF Data Services lub WebApi, ale jestem bardzo świadomy, że HTML / JS jest również głównym graczem. Wspomniałem tylko o korzyściach, jakie znalazłem, mając do czynienia z Silverlight UI, lub ASP.NET Kod po stronie serwera itp. Wierzę, że wraz z pojawieniem się" IndexedDB "w HTML5 / JavaScript, że mając "kontekst danych" i framework LINQ w JavaScript może również stać się dostępny, dzięki czemu możliwość odpytywania usług OData jeszcze łatwiej z JavaScript (możesz używać DataJS dzisiaj z Odatą). Dodatkowo używanie KnockoutJS do obsługi MVVM i wiązania W HTML/JS również sprawi, że będzie to proste:)]}

Obecnie badam, z której platformy korzystać. Byłbym zadowolony z korzystania z obu, ale mam tendencję do pochylania się w kierunku OData w oparciu o fakt, że moja następna aplikacja jest przede wszystkim o analityce (tylko do odczytu) i chcę bogate ekspresyjne API RESTful. Uważam, że OData + WCF Data Services daje mi to, ponieważ WebApi obsługuje tylko $take, $skip, $filter, $ orderby nad zbiorami. Nie Obsługa projekcji, Includes ($expand), itp. Nie mam zbyt wielu "aktualizacji / usuwania / wstawiania", a nasze dane są dość relacyjne.

Mam nadzieję, że inni dołączą do dyskusji i podzielą się swoimi przemyśleniami. Nadal decyduję i chciałbym usłyszeć inne opinie. Naprawdę uważam, że oba są świetne. Zastanawiam się, czy musisz nawet wybrać, dlaczego nie używać obu w razie potrzeby. Od klienta i tak chodzi o budowanie połączeń. Tylko myśl :)

Wierzymy, że Web API zapewnia właściwą platformę dla usług OData w przyszłości i jako takie będą inwestować przede wszystkim w tę platformę dla stosów serwerów OData. Będziemy oczywiście nadal stawiać znaczące zasobów do podstawowych bibliotek OData i klienta, ale planujemy zmniejszenie inwestycji w usługi danych WCF jako stos do tworzenia OData usługi.

OData Team Blog

Więc wydaje się, że teraz wszystko jest jasne wystarczy

Zarówno Web API, jak i usługi danych WCF obsługują OData po wyjęciu z pudełka. Dzięki WCF Data Services (WCFDS) jest to automatyczne. W Web API zwróć IQueryable z kontrolera i oznacz metodę [Queryable]. Dzięki temu uzyskasz funkcjonalność $filter, o której mówiłeś. A jeśli zrobisz to w ten sposób, oba mogą obsłużyć JSON w odpowiedzi automatycznie, umieszczając accept=application/json w nagłówku żądania. OData z WCFDS obsługuje kilka słów kluczowych więcej niż Web API (chociaż tylko $expand słowo kluczowe przychodzi na myśl), ale jestem pewien, że czas to naprawi.

Zarówno klienci. NET, jak i strony HTML mogą łatwo wywołać obie te alternatywy, ale jeśli lubisz LINQ i budujesz klientów. NET, WCFDS może zostać dodany do twojego projektu jako odniesienie do usługi. Pozwala to całkowicie pominąć całą działalność HTTP i bezpośrednio odpytywać zbiory.

Najważniejsze jest to, że nic nie stoi na przeszkodzie, aby umieścić .pliki svc do twojego ASP.Net projekt MVC. Informatyka to nie jest propozycja albo albo. Dodanie usług danych do serwera pozwoli Ci zaoszczędzić konieczność pisania wielu kontrolerów, ale nie uniemożliwia pisania dodatkowych kontrolerów, jeśli chcesz.

Innymi słowy:

Jeśli chcesz szybko ujawnić model danych (EDM lub inny) i nie potrzebujesz dużo kodu lub logiki biznesowej, WCF usługi danych ułatwiają to i będą dobrym punktem wyjścia.

Jeśli budujesz API i po prostu chcesz ujawnić niektóre zasoby (i logikę) za pomocą składni zapytań OData lub formatowania, to ASP.NET Web API jest prawdopodobnie najlepszym miejscem do rozpoczęcia.

Http://mattmilner.com/Milner/Blog/post/2013/04/02/WCF-Data-Services-and-Web-API-with-OData;-choices-choices.aspx

Devaron dał najbardziej pouczającą recenzję WCF vs Web Api, której jeszcze nie znalazłem. Dzięki. Teraz do punktu WCF jest zbyt skomplikowane, powiem, że złożoność nie jest automatycznie negatywne. Będziesz wdzięczny za pokój oddechowy, który Ci zapewni w przyszłości. Wyzwaniem, jak zawsze w przypadku narzędzi Microsoft, jest to, że nie znamy ani nie kontrolujemy tej przyszłości. Miejmy nadzieję, że Microsoft skończy z bardziej zunifikowanym systemem i pozostanie na kilka lat.

Ja też mam wielki system do zbudowania, i to mnie podkreśla, że ścieżka nie jest bardziej jasna. Planuję wstrzymać się jeszcze przez kilka miesięcy, kiedy wszystko się ułoży. I osobiście kibicuję datajs (sprawdź też JayData)

Po prostu ujmij to w najprostszy sposób, odsuń się od bazowego protokołu i spójrz na to z perspektywy dewelopera/użytkownika. Web API jest pierwszą klasą Microsoft HTTP oparte Rest Framework nie WCF. Oznacza to, że wszelkie brakujące funkcje Rest, specyfikacje zostaną dodane do interfejsu API www, a niekoniecznie do WCF.

Tak, możesz zaimplementować je samodzielnie w WCF, ale jak to jest napisane w zdaniu, musisz zaimplementować je samodzielnie.

Właśnie jako przykład dzisiaj implementujący Uwierzytelnianie dwuskładnikowe dla Web API zajmuje mniej niż 15 minut przy użyciu OWIN, który jest przede wszystkim pakietem uwierzytelniania/autoryzacji nuget, który rozpoczął się jako projekt open source.

Kiedy używasz stosu technologii, używanie stosu pierwszej klasy dla Microsoft robi ogromną różnicę. Będziesz miał nawet niezliczone ms opublikowane przykładowy kod i projekty w Github, które można po prostu skopiować i zrobić fory w swoim własnym projekcie. Robi różnicę na każdym poziomie, dokumentacja, próbki kodu, zestaw funkcji, wsparcie, helper api s nazwę go.

Więc moja prosta rada dla Ciebie, jeśli chcesz budować aplikacje oparte na http Restfull użyj web API (lub ASP.NET Core dla przenośności) i naprawdę trzymać się z dala od WCF. Jeśli protokół nie jest HTTP i tak naprawdę nie może być HTTP, użyj WCF.

To jest TL; DR odpowiedź na to pytanie.

WCF jest swiss army knife to śrubokręt WEB API do komunikacji i transferu danych: WCF może zrobić wszystko, co WEB API może zrobić, ale jeśli potrzebujesz więcej (np. używając protokołu TCP), WCF jest drogą do zrobienia.

Oto świetne porównanie .

WEB API

Numer jeden powód, aby używać WEB API jest to, że jest lekki. Oznacza to, że jest ono prostsze do wdrożenia, łatwiejsze do nauczenia się, łatwiejsze do utrzymania, itp. On specjalnie zaprojektowany dla sieci Web, która wymaga RESTful web services przez HTTP. Robi to i robi to dobrze. Jeśli to wszystko, czego potrzebujesz, WEB API jest prawdopodobnie najlepszym rozwiązaniem.

Również, jest Open Source (jeśli Ci zależy)

WCF

WCF robi znacznie więcej niż WEB API: obsługuje wiele protokołów transferu, wiele wzorców wymiany (WEB API wymaga integracji z SignalR lub Web Socketami), usługi SOAP mogą być opisane w WSDL, posiada dodatkowe funkcje bezpieczeństwa i więcej. Jeśli potrzebujesz tej dodatkowej funkcjonalności, skorzystaj z WCF.

OData

OData jest po prostu

Otwarty protokół pozwalający na tworzenie i wykorzystywanie queryable i interoperacyjnych interfejsów API RESTful w prosty i standardowy sposób. Źródło: http://www.odata.org/

Innymi słowy, wysoki poziom, to tylko standaryzacja specyficznej gramatyki dla RESTful HTTP requests. Które zapewnią takie same korzyści jak każdy protokół. I od co najmniej 2013 zarówno WCF, jak i WEB API pozwalają na korzystanie z OData. Więc pewnie nie warto martwić się o Odatę.