Существует ли общий метод проверки того, поддерживается ли определение свойства поставщиком Linq, особенно OData?

Я успешно выполнил следующую инструкцию с NorthWind.sdf в LinqPad:

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

В то же время мне не удалось выполнить аналогичный оператор со службой Odata (http://services.odata.org/northwind/northwind.svc) в LinqPad:

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

Ошибка: «Создание или инициализация экземпляров типа ‹>f__AnonymousType0`3[System.Int32,System.String,System.Int32] с выражением s.Orders.Count() не поддерживается».

Я знаю, что служба OData очень ограничена в поддержке Linq. В моем приложении есть поддержка динамических операторов Linq. На самом деле я пытаюсь перенести источник данных с Compact SQL Server на службу OData.

Поэтому мне приходится иметь дело с NotSupportedException в общем виде. В настоящее время я пытаюсь проверить синтаксис определения свойства перед его запуском, например

"s.Orders.Count() as Count"

Он прошел мою проверку, но встретил исключение NotSupportedException для OData.

Есть ли способ проверить, поддерживается ли определение свойства (строкой или лямбда) поставщиком Linq?

Любые предложения приветствуются.

Ин


.net odata linq
person Ying    schedule 22.06.2010    source источник

Ответы (2)


arrow_upward
6
arrow_downward

К сожалению, не существует общего программного способа проверки того, сможет ли поставщик LINQ преобразовать любой заданный запрос. Как правило, вам придется прибегнуть к документации или (чтобы быть уверенным) на самом деле попробовать запросы, как вы это делаете.

Однако разные провайдеры могут предоставлять некоторый механизм создания некоторого представления для запроса, который вы можете использовать, чтобы проверить, будет ли запрос работать без необходимости его выполнения.

В случае клиента OData вы можете вызвать .ToString() для запроса, и он должен вернуть URL-адрес, если сможет успешно обработать запрос; в противном случае будет возвращено сообщение об ошибке, похожее на «Ошибка перевода выражения Linq в URI: ...» (фактическое сообщение об ошибке может измениться в зависимости от языка пользователя, но оно определенно не будет действительный URI).

person Marcelo Lopez Ruiz    schedule 11.02.2011
comment
@Ying: Это звучит как ответ для меня. Если это так, вы можете принять это. - person chiccodoro; 30.03.2011

arrow_upward
2
arrow_downward

К сожалению, единственный способ выяснить это — протестировать конкретный запрос или просмотреть документацию, если создатель поставщика LINQ предоставил подробный список того, что не поддерживается.

Сам LINQ имеет очень свободную спецификацию, в значительной степени определяемую методами расширения, определенными в IQueryable/IEnumerable. Внедрение поставщика LINQ означает, что вам необходимо реализовать перевод над источником данных, например. LINQ to SQL преобразует дерево выражений, выраженное в запросе LINQ, в SQL, понятный поставщику базы данных. Каждый источник данных имеет свои собственные ограничения, которые в конечном счете определяют, что может поддерживаться, и аналогичным образом каждый поставщик LINQ может решить реализовать (или не реализовать) какой-либо конкретный метод или поведение.

Возможно, это просто ограничение поставщика внутри LINQPad для работы с OData — вместо этого вы можете проверить OQuery и посмотреть, предоставляет ли он лучший набор возможностей для вас — взгляните на http://beta.code.msdn.microsoft.com/OQuery-Building-OData-d2e75eed для получения подробной информации и загрузки.

person turtlespin    schedule 15.02.2011