OData поверх 2+ OData Feeds

Question

Скажите, у меня есть следующая модель

Я хотел бы представить единый фронт для этих каналов OData своим клиентам.

Есть ли хороший способ с OData сделать это? Или я должен просто взять IQueryables из каналов OData и создать конечную точку отражения поверх них?

Если я использую отражающий материал поверх OData, который общается с базой данных (через Entity Framework), с какими проблемами я столкнусь?

Answer 1

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

Основная идея состоит в том, что вы унифицируете метаданные $ (если ваша модель статична, вы можете сделать этовручную, если нет, вы сможете довольно легко написать какой-нибудь инструмент «слияния», а затем предоставить служебный документ, который указывает на соответствующие URL-адреса для каждого набора сущностей.В клиенте служб данных WCF теперь есть поддержка таких сервисов через распознаватель наборов сущностей: http://blogs.msdn.com/b/astoriateam/archive/2010/11/29/entity-set-resolver.aspx Последний CTP с такой поддержкой находится здесь: http://blogs.msdn.com/b/astoriateam/archive/2011/06/30/announcing-wcf-data-services-june-2011-ctp-for-net4-amp-sl4.aspx

Answer 2

Недоволен текущим принятым ответом на этот вопрос, для меня это скорее анти-ответ, чего не делать. Мое решение здесь применимо сегодня так же, как и в '11

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

Еще один термин для этой концепции - Sharding, у MS есть некоторые инструменты и API, которые могут помочь. Это достаточно простое пошаговое руководство: Инструменты базы данных SQL Azure Elastic: Shard Elasticity , но вы можете сделать это довольно легко из первых принципов.

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

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

2. Используйте базу данных master / header / mapping для хранения вашей конфигурации.

   Эта база данных имеет отдельную схему, основная цель которой - получить правильную строку подключения для каждого запроса. В большинстве случаев мы объединяем это с процессом аутентификации, и в этом случае вы сохраняете аутентификацию в этой центральной базе данных, а не в отдельных базах данных.

С точки зрения контроллера OData, даже с WCF Data Services вам просто нужно реализовать свою логику для получения строки подключения и использовать ее при создании экземпляра контекста данных.

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