Использование apicontroller vs odata EntitySetController

Ответ 1

почему я должен использовать EntitySetController, который наследует от контроллера odata вместо ApiController

• Я согласен с тем, что это сбивает с толку и что документации, кажется, не хватает (по крайней мере, когда у меня был тот же вопрос, что и вы). То, как я чувствовал себя непринужденно, просто прочитал код. Я призываю вас сделать то же самое, поскольку это действительно очень коротко (сосредоточьтесь на классе EntitySetController и его helpers); не должно занимать более 5-10 минут (обещание), и после этого у вас не возникнут вопросы.

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

Почему EF часто упоминается в контексте OData. Я знаю, что это "представляет" сущность, но я не понимаю, почему они связаны. Первый - это уровень обслуживания, а EF - модель.

• Это тоже смутило меня бесконечно, пока я не сдался и не посмотрел на происхождение OData, служб данных WCF (ранее ADO.NET Data Services) и спецификации OData (было указано, что версии протокола OData Core по-прежнему указаны с заголовком "DataServicesVersion" ). Там вы можете обнаружить, что OData использует EDM, модель данных сущности, которая является той же модельной спецификацией, используемой EF, и сериализует ее в том же формате как EF: CSDL (концептуальный язык определения схемы). Это не совпадение, WCF Data Services имеет первостепенную поддержку EF, и, хотя он не требует этого, можно сказать, что его дизайн был основан на нем.

  Обратите внимание, что WCF Data Services по-прежнему является флагманской реализацией OData.

Что-то, что потенциально представляет большой интерес (по крайней мере, это было для меня): при использовании EF с ASP.NET Web API и расширениями OData нет способа (насколько я знаю) поделиться моделью между двумя.

Вы можете перейти к следующей отправной точке для следующего ответа, если вы не нашли это интересным.

Например, при использовании EF в настройке Code-First вы, как правило, создаете свою модель в основном на условных обозначениях кода и EF System.Data.Entity.DbModelBuilder ( "API жидкости" ). Затем вы будете использовать System.Web.Http.OData.Builder.ODataConventionModelBuilder, который будет делать почти то же самое, что и для построения модели OData, и придет почти одинаково точно результат. Раньше мне удавалось выкапывать некоторые случайные заметки из случайной встречи либо из команды EF, либо из команды веб-API, которая упоминала это кратко, и насколько я помню (я больше не могу найти этот документ), там не планировали улучшать ситуацию. Таким образом, теперь они имеют две разные и несовместимые реализации EDM.

Я признаю, что не нашел времени, чтобы пройти через код, чтобы проверить это правильно, но я знаю, что расширения Web API + OData зависят от EdmLib (который предоставляет Microsoft.Data.Edm, первоначально разработанный для служб данных WCF), в то время как EF не делает, и вместо этого использует свой собственный System.Data.Entity.Edm. Я также знаю, что их разработчики на основе конвенций отличаются друг от друга, как объяснялось выше. Это смешно, когда вы используете EF в настройке DB-First; вы получаете сериализованную модель EDM в формате CSDL в файле EDMX, а расширения OData продолжаются и генерируют собственный код CSDL с сериализацией во время выполнения из CLR-код (с использованием отдельных условных кодов), который генерируется EF из исходного CSDL с помощью шаблонов T4. Ваша голова сильно вращается?

Обновление: Это было в значительной степени улучшеночуть меньше двух недель назад (19 июля), извините, я пропустил это. (Спасибо RaghuRam Nadiminti.) Я не просмотрел патч, но из кода примера кажется, что способ его работы заключается в том, что нужно сериализовать модель в CSDL с помощью сериализатора EF EDMX, а затем десериализовать его с помощью парсера EdmLib используемые расширениями OData. Он по-прежнему немного похож на хак в настройках EF Code-First (по крайней мере, код CLR анализируется только один раз, но я бы предпочел, чтобы оба компонента использовали ту же самую модель с памятью). Например, ярлык можно использовать при использовании сценариев Model-First или Database-First, десериализируя файл EDMX, созданный VS напрямую. В этом последнем сценарии это на самом деле меньше похоже на хак, но опять же, одна модель была бы лучше. Я не знаю, что либо EF, возможно, переключится на использование EdmLib, или что EdmLib переключится на использование EF EDM, оба проекта действительно сильны в настоящее время, и блокираторы, вероятно, не просто технические проблемы. Команда ASP.NET, к сожалению, не может многое сделать в этом AFAICT.

Обновление: Случайно наткнулся на те заметки о встрече. Они действительно были из команды EF и указывают, что они не планируют работать над EdmLib.

Однако теперь я считаю, что это все хорошо. Причина в том, что если они закрывают все пробелы и удаляют все шаблоны и делают все правильно, они, по сути, окажутся там, где есть службы данных WCF, что является полностью интегрированным решением, в котором программист вводит код в конвейер через "Перехватчики". Для меня единственная причина для этого - из-за требований с открытым исходным кодом, но даже тогда я считаю более разумным попытаться защищать открытый код WCF-DS.

Теперь возникает вопрос: "Но что такое расширение Web API + OData?". Ну, это хорошо подходит, когда вам действительно нужны две разные модели для вашего хранилища данных и вашего веб-сервиса. Это хорошо подходит, когда дизайн "перехватчика" недостаточно гибкий, чтобы вы могли перевести между двумя моделями.

Обновление:. По состоянию на 27 марта 2014 года он официально, они попытаются закрыть эти пробелы, обесценить службы данных WCF в процессе. В очень ранних переговорах упоминается "обработчик", чтобы сделать это, скорее всего, обработчик HTTP ASP.NET(см. Комментарии к объявлению). Похоже, что в это очень мало планирования, так как они все еще проводят мозговой штурм, чтобы заставить ASP.NET Web API заполнять прецеденты служб данных WCF. Я упомянул эти прецеденты выше, в комментарии к объявлению, и в этот поток (начался за несколько дней до анонса).

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

Существует некоторое недоверие к тому, что ASP.NET Web API можно превратить в что-то полезное для использования в случаях использования данных в разумные сроки, поэтому некоторые люди предложили что MSFT пересмотрит свое решение. Вопрос о том, следует ли использовать ASP.NET для требований с открытым исходным кодом, также является спорным: службы WCF Data Services скоро будут открытыми, если все будет "хорошо", хотя и не благодаря какой-либо пропагандистской работе. (Это просто исходный дамп, неизвестно, будет ли кто-нибудь поддерживать его в этот момент.)

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

В остальном, есть вероятность, что со временем появится новое решение - даже лучше, чем WCF Data Services или веб-API, когда дело доходит до OData API. Хотя сейчас это выглядит немного хаотичным, команда MSFT OData получала довольно немного отзывов от своих клиентов относительно рано, поэтому есть надежда (особенно, если будущее решение должно быть одним, оно само по себе открыто). Этот переход, вероятно, будет болезненным, но обязательно просмотрите обсуждения вокруг этого в будущем.

Я не уверен, что я потрачу время на обновление этого сообщения; Я просто хотел подчеркнуть, что вещи, связанные с веб-API и службами данных, вот-вот меняются очень сильно, так как этот ответ по-прежнему время от времени поддерживается.

Обновление: RESTier (объявление), кажется, является результатом.

И, наконец, мое (личное) мнение: OData, несмотря на то, что это технически протокол RESTful HTTP, очень, очень, очень ориентирован на данные. Это абсолютно нормально (мы можем определить много разных типов интерфейсов с HTTP), и я, например, считаю, что все дебаты по ServiceStack vs OData неактуальны (я считаю, что они работают на разных уровнях в наших текущих, общих архитектурах). То, что я нахожу тревожным, - это люди, пытающиеся сделать API на основе OData похожим на ориентированный на поведение (или "ориентированный на процесс" или "ServiceStack" -подобный) API. Для меня соглашения URI OData и форматы представления ресурсов (Atom и JSON) вместе заменяют SQL, службы данных WCF "Interceptors Query" и "Change Interceptors" замените триггеры СУБД и Действия OData замените хранимые процедуры СУБД. С этой точки зрения вы сразу увидите, что если логика домена, которую вы должны поставить за свой OData API, слишком сложна или не очень ориентирована на данные, вы получите запутанные "действия", которые не учитывают принципы REST, и которые не чувствуют себя хорошо. Если вы рассматриваете свой OData API как чистый слой данных, вы в порядке. Вы можете скомпоновать службу поверх нее, как если бы вы поставили "сервисный уровень" поверх базы данных SQL.

И, таким образом, я не уверен, что расширение Web API + OData больше подходит. Если вам нужны принципиально разные модели, вероятно, ваше приложение не слишком ориентировано на данные (за исключением случаев, когда вы просто объединяете модели из разных источников или чего-то еще), а OData, таким образом, не подходит. Это знак, по крайней мере, вы должны рассматривать только веб-API (с SQL или OData ниже) или что-то вроде ServiceStack.

К лучшему или к худшему, Javascript-клиенты не могут говорить SQL с удаленным сервером. Возможно, в будущем с помощью API-интерфейсов браузера или, возможно, с помощью вариантов WebSockets, но прямо сейчас OData является самым близким к удаленному слою данных любой собирается получить для богатых клиентов JS, которые имеют тонкую или не серверную логику. Конечно, OData используется другими типами клиентов, но я бы сказал, что это особенно полезно на клиентской веб-платформе, где такие вещи, как Breeze.js или JayData, относятся к OData, что платформа Entity Framework для SQL.

Я прочитал и понял много литературной литературы о предмете, да, я пропустил, когда его лучшая практика

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

Ответ 2

Используйте EntitySetController, если вы хотите создать конечную точку OData. Используйте ApiController, если вы хотите вернуть общий JSON или XML или какой-либо другой формат (например, используя собственный форматтер).

В Web API, EF и OData не обязательно связаны. Вы можете написать конечную точку OData, которая не использует EF. Многие учебные пособия по веб-API используют EF, потому что EF-код в начале относительно легко показать в учебнике.:-)