2010-09-17 14 views
6

Musimy dostarczyć API dla kanału aktywności (myśl o Facebooku) i zdecydowaliśmy się dać OData spróbować. Korzystamy z .NET, więc zdecydowaliśmy się na usługę danych WCF, ale nie używamy Entity Framework (ani żadnego innego ORMa), więc użyjemy dostawcy Reflection. Ponieważ mamy złożoną logikę biznesową dla naszych metod wyszukiwania, postanowiliśmy ujawnić je jako operacje serwisowe. Chcemy jednak ujawnić Delete/Update i wybór pojedynczej encji jako normalny zasób REST OData. Moje pytanie brzmi: jak możemy zaimplementować źródło danych dla dostawcy refleksów, które ogranicza dostęp do kolekcji, ale umożliwia dostęp do pojedynczych encji (żądanych przez klucz), pozwala na wykonywanie zleceń DELETE/PUT/POST, a także umożliwia dostęp do zbiorów dzieci pojedynczych podmiotów (tj./Kategorie (1)/Produkty). Zasadniczo chcę tylko ograniczyć dostęp do podstawowych kolekcji (tj. Usługa/Kategorie lub usługi/produkty).Usługa OData WCF z dostawcą Reflection

Odpowiedz

5

Nie ma tu świetnej odpowiedzi.

Istnieją dwa ustawienia można używać wewnątrz InitializeService (..)

config.SetEntitySetAccessRule("Feed", EntitySetRights.ReadSingle); 
config.SetEntitySetPageSize("Feed", 1); 

Niestety ani robić dokładnie to, co chcesz:

  1. EntitySetRights.ReadSingle limity Ci powrocie tylko jeden obiekt z tego zestawu. Co nie powiedzie się, ponieważ nie pozwala na to/Categories (1)/Products AND pozwala również/Categories? $ Filter = ... na zwrócenie wiersza.
  2. SetEntitySetPageSize ogranicza ilość początkowego obciążenia trafiającego na serwer tylko do jednego rekordu, ale można wykonać polecenie $ skiptoken, aby przejść do pozostałych danych po jednym zapisie w tym samym czasie i podobnie jak (1) pozwala na arbitralne zapytania nie tylko kluczowe predykaty.

To pozostawia tylko jedną realistyczną opcję. Odwiedzenie wyrażenia LINQ i wypracowanie, jeśli zezwalasz na to, co jest próbowane.

Ponieważ korzystasz z dostawcy Reflection, musisz zasadniczo zawinąć produkty IQueryables, które są zwracane z klasy "context" i wyszukiwać nieprawidłowe zapytania, zanim je przekażesz.

Nie coś dla osób zemdlonych.

Jeśli zdecydujesz się pójść tą ścieżką, przyda Ci się moja IQueryable wrapping example, powinieneś też sprawdzić numer Viteks blog post series on Data Service expressions.

Nadzieja to pomaga

Alex (OData Program Manager)

+2

Dziękuję bardzo. W rzeczywistości, kiedy analizowałem opcje, czytałem twój przykład zawijania i niestandardową serię dostawców danych. Pierwsze rozwiązanie w rzeczywistości nie wygląda tak źle. Będę musiał sprawdzić, ile podmiotów będzie miało zbiory podrzędne i ile będę musiał obejść. Kolejną rzeczą, którą błądziłem, było to, czy w takich sytuacjach wystarczy rzucić wyjątek. Wydaje się złe, ale inne opcje też nie są ładne. Zawijanie IQueryable wydaje się naprawdę bolesne. Szczerze mówiąc wolałbym upuścić rozwiązanie OData i wybrać inny typ usługi niż to. – Stilgar