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

Я занимаюсь упражнением, в котором у меня, кажется, блокируются мыслительные процессы.

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

В идеале я хотел бы использовать службы данных WCF.

Один из способов представить это — служба ODATA указывает на местоположение файла, где может быть случайный (но действительный) файл CSV, и при указании на этот файл потребитель должен иметь возможность запрашивать и использовать язык ODATA для фильтровать, сортировать, группировать и т. д.

Присоединений нет. Это ОДНА таблица.

Другой способ думать об этом состоит в том, что это полностью неизвестная таблица данных до времени выполнения. (Обратите внимание, что не набор данных. Просто одна таблица данных.)

Предположительно, первичный ключ — это сконструированный столбец Row Number, поскольку ничто не гарантирует уникальность любого другого столбца.

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

Есть предположения?


person Stephan G    schedule 30.07.2013    source источник


Ответы (2)


Использование служб данных WCF для этого варианта использования позволит легко создать статически определенную конечную точку ODATA для уже существующей модели объекта, почти так же, как обычная служба WCF предоставляет определенный интерфейс службы, который вы определяете как производитель. Чтобы было ясно, это схема, которая определяется во время компиляции, а не во время выполнения.

Если вы хотите сделать больше, скорее всего, вам нужно написать свой собственный пользовательский провайдер, различные способы сделать это дадут вам все более мощные функции за счет того, что их будет сложнее реализовать. Хорошей отправной точкой является отличная серия блогов Алекса Джеймса, которая начинается здесь:

http://blogs.msdn.com/b/alexj/archive/2010/01/07/data-service-providers-getting-started.aspx

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

Один из способов обойти это — реализовать службу данных, которая предоставляет какую-то метамодель, пары ключ/значение, тройное хранилище и т. д. и т. д., однако это несколько уничтожает преимущества строгой типизации, которые вы получаете от использования ODATA, поэтому я бы не стал Я тоже не рекомендую этот подход.

person Jon G    schedule 30.07.2013
comment
Спасибо, Джон. Это хорошая ссылка, более полезная и полная, чем та, которую я использовал, а именно msdn. .microsoft.com/en-us/data/gg191846. Я нахожусь с написанием своего собственного настраиваемого поставщика, на самом деле это было в центре моего внимания. Я ожидаю этого. Но даже при написании собственного поставщика схема не знает схемы до тех пор, пока проблема времени выполнения кажется сложной. Просто не уверен, как думать о раскалывании ореха. - person Stephan G; 30.07.2013
comment
Я бы посоветовал поработать с его примерами и позаимствовать код из них, поскольку вам нужно начать. Это всего случай реализации IDataServiceMetadataProvider и IQueryProvider и нескольких других вещей, а затем их объединения! Я написал свой собственный провайдер около года назад, начав в основном с этого набора статей, так что это, конечно, не невозможно, если у вас есть время и желание. - person Jon G; 30.07.2013

для чего это стоит, бестиповые сущности теперь поддерживаются в WebAPI 2.0 OData, см. эту запись в блоге: http://blogs.msdn.com/b/leohu/archive/2013/11/05/typeless-entity-object-support-in-webapi.aspx

person stefjnl    schedule 26.11.2013