Каков самый простой способ преобразовать поставщика OData служб передачи данных WCF в Web API?

Question

В настоящее время я изучаю возможность преобразования нашего текущего поставщика OData WCF Data Services в OData Web API.

Я просто немного сбит с толку реализацией OData для Web API.С WCF Data Services он находится поверх нашего ADO.Модель Net entity, которая предоставляет множество таблиц из серверной части SQL Server, т.Е.вы предоставляете WCFDS модель ADO для генерации, а затем у вас есть доступ ко всем таблицам через стандартный синтаксис OData.

С помощью Web API из всего прочитанного до сих пор мы создаем контроллер или отдельные действия для каждой таблицы / объекта, которые мы хотим предоставить?Я что-то упускаю?Есть ли просто способ, при котором контроллер OData Web API может просто предоставить всю модель из модели данных ADO?Необходимость создавать действие для каждой таблицы была бы беспорядочной и излишней.

В настоящее время, если нам нужно добавить таблицу, мы просто сопоставляем ее в EDMX, и WCFDS автоматически предоставит ее, поскольку она сопоставлена со всем контекстом модели.

Answer 1

Генерация модели (моделей)

Ты можешь:

• Используйте разработчик конвенционной модели из ASP.NET Веб-API.Это генерирует модель, отличную от той, которую создает собственный конструктор конвенционных моделей EF:EdmLib - файл IEdmModel.Видишь этот вопрос хотя, если вы используете модель в первую очередь или базу данных в первую очередь.Этот метод кажется действительно обратным, и так оно и есть, но в основном он работает.
• Сериализуйте модель EF и перестройте ее как IEdmModel (см . этот вопрос).Опять же, это действительно неэффективно.Если вы используете model-first или database-first, вам нужно просто десериализовать EDMX-файл для создания IEdmModel.Внутренне он по-прежнему создает другую модель, но, по крайней мере, CDSL является более стабильным форматом, чем соглашения о коде CLR, поэтому у вас, вероятно, будет меньше сюрпризов, чем при использовании двух разных сборщиков моделей на основе соглашений.

Причина этого заключается в том, что ASP.NET Расширения OData веб-API используют EdmLib, в то время как EF использует свой собственный код, и нет никакого плана заставить их работать вместе.Может быть, ты найдешь эта напыщенная речь полезно, если вам интересно.

Работа над API

После того, как вы сгенерировали модель из уникального источника (чтобы вы могли работать над своей моделью из одного места), вам действительно нужно будет создать контроллер для каждого объекта, в основном.Смысл Web API не в том, чтобы создавать что-то автоматически, а в том, чтобы предложить разработчику гибкость.Тот Самый EntitySetController помогает сократить избыточность, но не предлагает все "из коробки".

Делая шаг назад

В тираде, упомянутой выше, я также говорю о разнице между уровень обслуживания API и a уровень данных API.ASP.NET Веб-API лучше подходит для сервисов, в то время как OData делает сервисы неудобными.С другой стороны, OData упрощает доступ к данным (по сути, являясь чем-то вроде RESTful SQL) и, благодаря прямой привязке к модели данных, может автоматизировать многие вещи, как вы видели с WCF Data Services.ASP.NET Веб-API с расширениями OData находится посередине, и его значение не согласовано повсеместно (хотя использование определенных фрагментов синтаксиса OData URI в сервисных API, безусловно, полезно).

Не слишком увлекайтесь недавней шумихой вокруг ASP.NET Веб-API, it и службы передачи данных WCF - это очень разные устройства, которые работают на разных уровнях вашего дизайна.Действительно, в многоуровневой архитектуре вы вполне могли бы увидеть service API, созданный с использованием ASP.NET Web API, расположенный поверх OData API, созданного с использованием WCF Data Services.

Мой совет - тщательно подумайте о том, что вы пытаетесь создать, и в зависимости от ответа выберите либо ASP.NET Веб-API и примите во внимание тот факт, что API, который вы предоставляете, будет сильно отличаться от ориентированного на данные OData API, или придерживайтесь WCF Data Services.

Возможный план

Вы можете найти в Интернете много материалов об API сервисного уровня, выполнив поиск по таким терминам, как "не-CRUD web / RESTful / hypermedia API" или сравнив такие продукты, как ServiceStack, которые выступают за менее ориентированные на данные API.

Если вы все еще не уверены в характере вашего проекта, создайте его прототип.

• Если в итоге вы получаете набор по существу идентичных контроллеров с веб-API, каждый из которых сопоставлен ровно одному объекту, то ваш API в значительной степени ориентирован на данные. Используйте службы передачи данных WCF.
• Если вы в конечном итоге столкнетесь с большим количеством действий OData и неудобными объектами с WCF Data Services, то вам понадобится больше доменной логики на стороне сервера API, а ориентация на данные не предлагает вам достаточно. Используйте веб-API.Хорошее эмпирическое правило здесь заключается в том, чтобы относиться к действиям OData точно так же, как вы относитесь к хранимым процедурам в СУБД SQL.На самом деле, относитесь к любому серверу OData как к СУБД, потому что это то, чем они являются. Если вы не хотите размещать его за интерфейсом SQL, не размещайте его за интерфейсом OData.

Важно (Обновление)

27 марта 2014 года было объявлено, что Службы передачи данных WCF будут прекращено производство корпорацией Майкрософт в пользу ASP.NET Веб-API.Для обработки вариантов использования "уровня данных", которые я здесь представил, Microsoft заявила, что планирует расширить ASP.NET Web API.Некоторые Сообщество усилия также ведутся работы.Службы передачи данных WCF также в какой-то момент будут с открытым исходным кодом, так что не исключено, что новый сопровождающий возьмет управление на себя, хотя это и сомнительно.