Czy istnieje ogólna metoda sprawdzania, czy właściwość zdefiniowana obsługiwana przez dostawcę Linq, w szczególności OData?

Question

pomyślnie prowadził następujące oświadczenie z NorthWind.sdf w LINQPad:

from s in Shippers 
    select new 
{ 
    s.ShipperID, 
    s.CompanyName,  
    Count=s.ShipViaOrders.Count()  
} 

Jednocześnie, nie udało mi się uruchomić podobne oświadczenie z Serwisu OData (http://services.odata.org/northwind/northwind.svc) w LINQPad:

from s in Shippers  
select new 
{ 
    s.ShipperID, 
    s.CompanyName,  
    Count=s.Orders.Count()  
} 

Błąd: "Konstruowanie lub inicjowanie wystąpień typu <> f__AnonymousType0`3 [System.Int32, System.String, System.Int32] z wyrażeniem s.Orders.Count() nie jest obsługiwane.".

Wiem, że usługa OData jest bardzo ograniczona w obsłudze Linq. Mam dynamiczną obsługę instrukcji Linq w mojej aplikacji. Właściwie próbuję przenieść źródło danych z Compact SQL Server do usługi OData.

Tak więc mam do czynienia z wyjątkiem NotSupportedException w sposób ogólny. Obecnie staram się sprawdzić składnię własności zdefiniowania przed uruchomieniem go, takiego jak

"s.Orders.Count() as Count" 

Minęło czek, ale spotkał się z NotSupportedException OData.

Czy istnieje sposób sprawdzenia, czy właściwość zdefiniować (przez ciąg lub lambda) jest obsługiwana przez dostawcę Linq?

Wszelkie sugestie są mile widziane.

Ying

Answer 1

Niestety nie ma ogólnego programistyczny sposobem na sprawdzenie, czy dostawca LINQ będzie w stanie przetłumaczyć dowolny danego zapytania. Zazwyczaj będziesz musiał uciekać się do dokumentacji lub (na pewno) faktycznie wypróbować zapytania w trakcie pracy.

Różni dostawcy mogą jednak zapewnić pewien mechanizm generowania pewnej reprezentacji dla zapytania, co może być przydatne do sprawdzenia, czy zapytanie będzie działało bez konieczności jego wykonywania.

W przypadku klienta OData można wywołać funkcję .ToString() w zapytaniu i powinna ona zwrócić adres URL, jeśli jest w stanie pomyślnie przetworzyć zapytanie; w przeciwnym razie zwróci komunikat o błędzie, który wygląda podobnie do "Błąd tłumaczenia wyrażenia Linq na URI: ..." (rzeczywisty komunikat o błędzie może się zmienić w zależności od języka użytkownika, ale będzie to zdecydowanie nie być prawidłowym identyfikatorem URI).

Answer 2

Niestety, jedynym sposobem, aby się tego dowiedzieć, jest przetestowanie konkretnego zapytania lub dokumentacji, jeśli twórca dostawcy LINQ podał szczegółową listę elementów, które nie są obsługiwane.

Sam LINQ ma bardzo luźną specyfikację w dużej mierze zdefiniowaną przez metody rozszerzeń zdefiniowane w IQueryable/IEnumerable. Wdrożenie dostawcy LINQ oznacza, że ​​musisz zaimplementować tłumaczenie na źródle danych - np. LINQ to SQL tłumaczy drzewo wyrażenia wyrażone w zapytaniu LINQ na SQL, które jest rozumiane przez dostawcę bazy danych. Każde źródło danych ma własne ograniczenia, które ostatecznie decydują o tym, co może być obsługiwane, i podobnie każdy dostawca LINQ może wybrać implementację (lub nie wdrożyć) jakiejkolwiek konkretnej metody lub zachowania.

Może to być tylko ograniczenie dostawcy w LINQPad do obsługi OData - możesz zamiast tego sprawdzić OQuery i sprawdzić, czy zapewnia on lepszy zestaw możliwości - spójrz na http://beta.code.msdn.microsoft.com/OQuery-Building-OData-d2e75eed w celu uzyskania szczegółowych informacji i pobrania.