2010-03-22 10 views
2

Я работаю над универсальным поставщиком OData, чтобы идти против пользовательского поставщика данных, который у нас есть. Thsi полностью динамичен в том, что я запрашиваю поставщика данных для таблицы, которую он знает. На данный момент у меня есть базовая структура хранения, основанная на примере кода OData.Выполнение существующего запроса LINQ к динамическому объекту (например, DataTable)

Моя проблема: OData поддерживает запросы и ожидает, что я передам реализацию IQueryable. На lowe rside у меня нет поддержки запросов. Не шутка - поставщик возвращает таблицы, а предложение WHERE не поддерживается. Производительность здесь не проблема - таблицы небольшие. Хорошо их сортировать в поставщике OData.

Моя основная проблема в этом.

  • Я представляю инструкцию SQL для вывода данных таблицы. В результате здесь есть какой-то читатель данных ADO.NET.
  • Мне нужно выставить реализацию IQueryable для этих данных, чтобы потенциально разрешить более позднюю фильтрацию.

Любой идеал, чтобы лучше всего коснуться этого? Только .NET 3.5 (в течение некоторого времени не запланировано 4.0). Я серьезно думал о создании динамических классов DTO для каждой таблицы (испускание байт-кода), поэтому я могу использовать стандартный LINQ. Прямо сейчас я использую словарь для каждой записи (не слишком эффективный), но я не вижу реального способа фильтрации/сортировки на их основе.

+0

Как вы хотите использовать фильтрацию, если у вас нет объектов (или структур) для запроса предикатов. Насколько я вижу, вам необходимо предоставить вашу реализацию IQuerable. Таким образом, Вы переводите выражения в делегаты, которые фильтруют результирующий набор. – luckyluke

+0

Технически я полностью в порядке на данный момент НЕ запускать ЛЮБАЯ фильтрацию и просто игнорировать ее;) Существует множество открытых таблиц, которые в основном используются для заполнения выпадающих списков - и ряд «хранимых процедур», которые выполняют фильтрацию в логике так или иначе. – TomTom

ответ

0

Пабло Кастро, один из главных голосов, стоящих за OData, говорит, что доставка OData-сервиса без возможности запроса полностью соответствует их намерениям. См. Сообщение this.

Это одна из причин, по которой я действительно хотел бы, чтобы они реализовали ссылку «поиск» в ответе OData, чтобы клиентское приложение могло определить, доступны ли возможности запроса или нет. Что-то вроде OpenSearch.

<Link rel="search" type="application/ODataQuery+xml" href="QueryMetadata.xml"/> 

Таким образом, клиент может легко обнаружить, реализуется ли поиск или нет.

1

Если вы в порядке с выполнением запроса внутри поставщика OData, вы можете просто загрузить свои данные в список T (T - тип объекта), а затем просто вернуть список. AsQueryable(). Это вернет LINQ to Objects query, который обеспечивает полную поддержку всех параметров запроса и основан на хранении в памяти (список). Обратите внимание, что для правильной работы ваш IDataServiceQueryProvider.IsNullPropagationRequired должен возвращать значение true (поскольку LINQ to Objects требует корректного распространения нулей в запросе). Также, если вы установите CanReflectOnInstanceProperty где-нибудь в false, вам нужно будет выполнить переписывание запроса. Если это так, посмотрите на этот пост here для получения информации о том, как доступны свойства.