OData z ServiceStack?

Edit

ServiceStack dodał teraz Auto Query, które jest naszym podejściem do włączania usług opartych na danych, które unikają pułapek i anty-wzorców promowanych przez OData.

---

Czy ServiceStack obsługuje OData.

Nie. W każdym razie nie bezpośrednio. Jeśli ktoś widzi jakąkolwiek wartość w OData, może dodać niezbędną funkcjonalność jako opcjonalną wtyczkę - ale nigdy nie zostanie ona wbudowana w rdzeń ServiceStack.

Słabe praktyki rozwojowe

OData nie nadaje się do ServiceStack, który gwałtownie sprzeciwia się ciężkim abstrakcjom i "magicznemu zachowaniu", które postrzegamy jako klasyczny przykład {5]}: {]}

Każda minuta, którą oszczędzasz, gdy twój fantazyjny framework robi magiczne rzeczy, aby pomóc ci koszty przyszłości - masz dziesięć minut debugowania. Nie warto.

Nie sądzimy, że poleganie na magicznych zachowaniach blobów z czarnej skrzynki wytrzyma próbę czasu. Historycznie ilekroć użyliśmy tego (np. ADO.NET zestawy danych, ASP.NET Dynamic Data) szybko natknęliśmy się na nieodłączne-elastyczne ograniczenia tych frameworków, które są w-zdolne do ewoluowania w celu wspierania nowych praktyk programistycznych, paradygmatów i technologii, do których nie zostały zaprojektowane, co skutkuje szybkim wycofaniem się na rzecz nowszych frameworków, które mogą. To jest cykl ponownego pisania, którego nie chcemy promować.

Promuje złe praktyki w serwisach internetowych

OData także Promuje anty-wzorzec, w którym ujawnia wewnętrzne szczegóły implementacji Twojej usługi, ściśle łącząc ukrytą umowę o świadczenie usług z bazowymi tabelami RDBMS, dając Ci ograniczoną kontrolę nad możliwościami buforowania, ponownego faktoringu lub możliwości wersji Twoich usług w przyszłości.

Jest to podobne do przekazania łańcucha połączenia db, gdzie gdy tylko masz klientów w produkcji wiążących się z nim, struktura tabel stają się zamrożone hamując zdolność do ewolucji Twoje istniejące tabele DB, ponieważ może potencjalnie złamać istniejących klientów. Rekomendacja ServiceStack polega na tym, aby Twoi klienci byli związani z dobrze zdefiniowaną warstwą usług, którą możesz ponownie uwzględnić w implementacji.

Podsumowując OData rzeczywiście zapewnia bogatą funkcjonalność, ale osobiście nie polecam jej stosowania poza intranetem, gdzie nie kontrolujesz i możesz wdrożyć zarówno Klienta, jak i serwera.

WebApi jest najlepszą opcją z ukrytym wsparciem dla oData poprzez zwracanie interfejs IQueryable<T>.

Używane tylko w technologiach Microsoft only

Jedną z głównych zalet usług internetowych / zdalnych (a w szczególności SOA) jest to, że zapewnia niezależną od technologii i interoperacyjną fasadę nad każdą funkcjonalnością, którą chcesz ujawnić. Chociaż OData jest standardem otwartym, sama technologia została zasadniczo przyjęta tylko przez Microsoft i inicjatywy związane z.NET .

OData jest wolna

OData sama znalazła się powolne (co jest sprzeczne z naszymi podstawowymi celami) i brak kontroli nad implementacją utrudnia czyste wdrożenie technik zwiększających wydajność, takich jak buforowanie nad nią.

Konkretny przykład

Podałem konkretny przykład w komentarzach, dlaczego oData jest złym pomysłem, na końcu IQueryable is Tight Coupling post, który powtórzę tutaj dla zachowania:

Cała idea interfejsów usług internetowych polega na ujawnieniu niezależne od technologii interoperacyjne API dla świata zewnętrznego.

Odsłanianie punktu końcowego IQueryable / OData skutecznie łączy twoje usługi korzystania z OData w nieskończoność, ponieważ nie będziesz w stanie określ, z jaką "przestrzenią zapytań" są powiązane istniejące klienty, czyli co istniejące zapytania/tabele/widoki / właściwości, które musisz zamrozić / wsparcie na czas nieokreślony. Jest to problem przy ujawnianiu jakiejkolwiek implementacji w powierzchni interfejsu API, ponieważ ogranicza możliwość dodawania własnych niestandardowa logika na nim, np. autoryzacja, buforowanie, monitorowanie, Ograniczanie szybkości itp. A ponieważ OData jest bardzo powolny, trafisz problemy z wydajnością / skalowaniem na wczesnym etapie. Brak kontroli nad punkt końcowy, oznacza, że skutecznie zmierzasz do przepisania: https://coldie.net/?tag=servicestack

Zobaczmy, jak wykonalne byłoby odejście od dostawcy oData implementacja poprzez spojrzenie na istniejące zapytanie z OData Netflix API:

Http://odata.netflix.com/Catalog/Titles?$filter=Type%20eq%20'Movie'%20and%20(Rating%20eq%20'G'%20or%20Rating%20eq%20'PG-13')

Ta usługa jest teraz efektywnie połączona z tabelą / widokiem o nazwie "Titles" z kolumną o nazwie "Type".

I jak to byłoby naturalnie napisane, gdybyś nie używał Odaty:

Http://api.netflix.com/movies?ratings=G, PG-13

Teraz, jeśli z jakiegokolwiek powodu musisz zastąpić implementację istniejącej usługi (np. pojawiła się lepsza platforma technologiczna, działa zbyt wolno i musisz przenieść ten zestaw danych na NoSQL/Full-TextIndexing-backed sln) ile wysiłku potrzeba by zastąp impl OData (który jest skutecznie powiązany ze schematem RDBMS i OData binary impl) do bardziej intuicyjnego zapytania impl-agnostycznego na dole? Nie jest to niemożliwe, ale jako że jest to niezwykle trudne do zaimplementuj API OData dla nowej technologii, która przepisuje + łamie istniejące preferowaną opcją są Klienci.

Pozwalając implementacjom wewnętrznym dyktować zewnętrzny adres URL struktura to pewny sposób na złamanie istniejących klientów, gdy rzeczy MUSZĄ zmiana. Dlatego powinieneś ujawniać swoje usługi za fajnymi Uri, tj. logiczne permanentne adresy URL (które nie są utrudnione przez implementację) które się nie zmieniają, ponieważ na ogół nie chcesz ograniczać wybór technologii Twoich usług.

To może być dobra opcja, jeśli chcesz realizacja adhoc" usługi " na it, ale to nie jest coś, czego bym nigdy nie chciał zewnętrznych klientów binded to in a production system. I jeśli mam tylko zamiar ograniczyć jego użyj do mojego lokalnego intranetu jakie ma zalety nad samym dawaniem z łańcucha połączeń tylko do odczytu? które pozwolą innym korzystać z ich ulubiony SQL Explorer, raportowanie lub inne narzędzia, które mówią SQL.

Update

Netflix właśnie wycofał swój katalog OData, skuteczny na 8 kwietnia 2013.

Dodano nową odpowiedź na dlaczego zalecamy używanie czystych, dobrze zdefiniowanych nieskażonych DTO do definiowania dowolnych usług zdalnych za pomocą , co jest najlepszą praktyką usług zdalnych, której używanie OData nie promuje.

Dobry artykuł o tym, dlaczego generyczne interfejsy API, takie jak OData, są znacznie bardziej kruche, złożone i trudniejsze w użyciu niż równoważne interfejsy intencyjne.