Службы данных WCF (OData) Vs ASP.NET Web API

Я разрабатываю распределенное приложение, которое будет состоять из служб RESTful и различных клиентов (Silverlight, iOS, Windows Phone 7 и т. д.). Прямо сейчас я определяю, какую технологию я должен использовать для реализации моих служб, WCF Data Services (OData) или новой ASP.NET веб-API, который выходит с ASP.NET MVC 4.

Я смотрел несколько презентаций в интернете о каждом, и сейчас я склоняюсь к службам данных WCF в первую очередь из-за механизмов фильтрации встроенный в URI и собственные возможности гипермедиа. Единственный недостаток, который я вижу, - это многословие спецификации Atom Pub в отличие от POX.

есть ли что-нибудь, что я должен знать об этих двух технологиях, прежде чем принимать решение? Зачем кому-то выбирать? ASP.NET веб-API через службы данных WCF?

8 ответов


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

Я согласен с Дэйв Уорд на этой. Проверить свой блог для получения дополнительной информации.

Я долго держался против давления, чтобы перейти от ASMX к WCF в Проекты WebForms, потому что принятие сложности WCF в первую очередь только наградил меня менее гибкой сериализацией JSON. Напротив, я начал конвертировать некоторые из моих проектов из ASMX в Web API и был доволен тем, как легко Web API заменяет ASMX.

Я считаю, что Microsoft наконец-то нашла хороший баланс между ASMX простота и сила WCF с Web API.


в настоящее время существуют другие основные различия между WebAPI и WCF Data Services, о которых никто никогда не упоминает. Я хотел бы, чтобы MS вышла с хорошей статьей, сравнивающей эти два.

Я следил за OData некоторое время, а также WebApi. Я всегда находил несколько основных отличий.

во-первых, я не уверен, что ваш босс имеет в виду под "MS поддерживает WebApi", что означает, что они не поддерживают OData?? IMO, они поддерживают оба, и в настоящее время есть некоторые минимальные частично покрывать. Рынок данных Windows Azure предоставляет свои данные с помощью OData, хранилище таблиц Azure использует OData, SharePoint 2010 разрешает запросы OData к данным, а другие продукты MS также поддерживают его, например Excel PowerPivot. Это очень мощная структура запросов, когда дело доходит до реляционных данных. И потому, что это спокойный, любые языки, платформы, устройства и т. д. может интегрироваться с ней.

вот что мне нравится в OData + WCF Data Services:

данные OData + WCF Службы, наконец, позволили клиентским приложениям быть более "выразительными" при запросе данных через Интернет. Раньше нам всегда приходилось использовать ASMX или WCF для создания жестких веб-API, которые становятся громоздкими и требуют постоянных изменений, когда пользовательский интерфейс хочет чего-то немного другого. Клиентское приложение может указывать только параметры, определяющие критерии возврата. Или сделайте так, как я сделал, и "Сериализуйте" выражения LINQ и передайте их как параметры и re-hydrate в Expressions<Func<T,bool>> на сервере. Это прилично. Получил работу, но я хочу использовать LINQ на клиенте и перевести его через Интернет с помощью REST, что именно то, что позволяет OData, и я не хочу использовать свой собственный "Хак" решения.

это похоже на предоставление "TRANSACT SQL" без необходимости строки подключения к БД. Просто укажите Url и whoala! Запущен опрос. Конечно, как WebApi, так и Службы данных WCF поддерживают аутентификацию / авторизацию, поэтому вы можете управлять доступом, добавлять дополнительные операторы "Where" на основе ролей или другой конфигурации данных. Я бы предпочел сделать это в моем слое веб-Api, чем в SQL (например, построение представлений или хранимых процессов). И теперь, когда приложения могут сами создавать запросы, вы увидите, что инструменты отчетов ad-Hoc и BI начинают использовать OData и позволяют пользователям определять свои собственные результаты. Не полагаясь на статические отчеты, где они имеют минимальный контроль.

при разработке в Silverlight, Windows 8 Metro, или ASP.NET (MVC, WebForms и т. д.), Вы можете просто добавить "ссылку на службу" в Visual Studio в Службу данных WCF и быстро начать использовать LINQ для запроса данных, и вы получите " контекст данных "на клиенте, что означает, что он отслеживает изменения и позволяет" отправить " изменения атомарно обратно на сервер. Это очень похоже на услуги RIA для Silverlight. Я бы использовал службы данных WCF вместо служб RIA, но в то время он не поддерживал DataAnnotations или действия, но теперь это так:) службы данных WCF имеют еще одно преимущество перед службами RIA, которое возможность выполнения "проекций" от клиента. Это может помочь с производительностью, если я не хочу возвращать все свойства сущности. Наличие "контекста данных"на клиенте отлично подходит для работы с бизнес-приложениями.

Итак, службы данных WCF отлично подходят, если у вас есть данные с отношениями, особенно если вы используете SQL Server и Entity Framework. Вы быстро сможете предоставлять запрашиваемые данные + действия (вызовы для вызова операций, т. е. рабочих процессов, фона процессы) над остальными с очень небольшим кодом. Службы данных WCF только что были обновлены. Запущен новый релиз. Проверьте все новые функции.

недостатком служб данных WCF является "контроль", который вы теряете над стеком HTTP. Я обнаружил, что самый большой недостаток был в IQueryable<T> методы, возвращающие коллекции. В отличие от служб RIA и WebApi, у вас нет полного доступа для разработки логики в методе IQueryable. В службах RIA и WebApi вы можете писать любой код, который хотите как вы вернетесь IQueryable<T>. В службах WCF Data Services вы получаете доступ только для добавления оператора "Where" с помощью Expression<Func<T,bool>> методы перехватчика. Меня это разочаровало. Наше текущее приложение использует службы RIA, и я считаю, что нам действительно нужна возможность контролировать логику IQueryable. Надеюсь, я ошибаюсь в этом, и мне просто чего-то не хватает

кроме того, Службы данных WCF еще не полностью поддерживают все операторы LINQ. Однако он по-прежнему поддерживает больше, чем WebApi.

что о Веб-API???

  1. мне нравится контроль над Http-запросом / ответом
  2. легко следовать (используя шаблоны MVC). Я уверен, что больше инструментов придет.

на данный момент (насколько я понимаю), на клиенте нет поддержки "контекста данных" (т. е. Silverlight, ASP.NET серверный код и т. д.), Потому что WebApi на самом деле не касается моделей данных сущностей, таких как WCF Data Services/OData. Он может предоставлять коллекции объектов модели с помощью IQueryable/IEnumerable, но нет первичного ключа / внешнего ключа "свойства навигации" (т. е. клиент.Накладные) для использования после загрузки сущностей на клиенте, поскольку нет "контекста данных", который загружает их асинхронно (или в одном вызове с помощью $expand) и управляет изменениями. У вас нет сгенерированного кодом "представления" вашей модели данных сущности на клиенте, как в службах RIA или службах данных WCF. Я не говорю, что у вас нет/нет моделей в клиенте, которые представляют ваши данные, но у вас есть вручную заполнить данные и управлять, какие "счета-фактуры" должны быть установлены с каждым "клиентом" после их извлечения через Интернет. Это может быть сложно, особенно со всеми асинхронными вещами. Ты не знаешь, какие звонки придут первыми. Это может быть трудно объяснить здесь, но просто прочитайте о "контексте данных" в службах RIA или службы данных WCF. Поэтому при работе с бизнес-приложениями это главная проблема для меня. Это главным образом основано на урожайности и ремонтопригодность. Вы можете obsolulately создавать приложения без контекста данных. Это просто упрощает работу, особенно в Silverlight, WPF и теперь Windows 8 Metro. Иметь реляционные сущности, загруженные в память асинхронно и имеющие две привязки, действительно приятно иметь.

сказав это, означает ли это, что когда-нибудь WebApi может поддерживать "контекст данных" на клиенте? Думаю, может. Кроме того, с помощью дополнительных инструментов проект Visual Studio может генерировать все ваши методы CRUD на основе Схема базы данных (или Entity Framework).

кроме того, я знаю, что упоминаю .NET только для .NET Framework, когда дело доходит до работы с WCF Data Services или WebApi, но я очень знаю, что HTML/JS также является основным игроком. Я просто упомянул о преимуществах, которые я нашел при работе с интерфейсом Silverlight, или ASP.NET серверный код и т.д. Я считаю, что с появлением "IndexedDB" в HTML5 / JavaScript, что наличие "контекста данных" и LINQ framework в JavaScript также может стать доступно, что делает возможность запроса сервисов OData еще проще из JavaScript (вы можете использовать DataJS сегодня с OData). Кроме того, использование KnockoutJS для поддержки MVVM и привязки в HTML / JS также сделает его легким :)

в настоящее время я изучаю, какую платформу использовать. Я был бы рад использовать либо, но я склонен склоняться к OData на основе того факта, что мое следующее приложение в основном связано с аналитикой (только для чтения), и я хочу богатый выразительный RESTful Api. Я считаю, что данные OData + WCF Службы дают мне это, потому что WebApi поддерживает только $take, $skip, $filter, $orderby над коллекциями. Он не поддерживает прогнозы, включает ($expand) и т. д. У меня нет много "обновлений/удалений/вставок" и наши данные довольно относительны.

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


мы считаем, что Web API предоставляет правильную платформу для сервисов OData идти вперед и как таковой будет инвестирование в первую очередь в эту платформу для стеков сервером. Мы, конечно, будем продолжать ставить значительные ресурсы в основные библиотеки OData и клиент, но мы планируем сокращение инвестиций в службы данных WCF как стек для создания OData сервисы.

Команда OData Блог

Итак, кажется, теперь все достаточно ясно


веб-API и Службы данных WCF поддерживают OData из коробки. С WCF Data Services (WCFDS) это происходит автоматически. С помощью Web API верните IQueryable от вашего контроллера и пометить метод с [Queryable]. Это даст вам $filter функциональность, о которой вы говорили. И если вы идете об этом таким образом, оба могут обрабатывать JSON в ответе автоматически, помещая accept=application/json в заголовке запроса. OData из WCFDS поддерживает несколько ключевых слов OData, чем веб-API (хотя только the $expand ключевое слово приходит на ум), но я уверен, что время исправит это.

клиенты .NET и HTML-страницы могут легко вызывать обе эти альтернативы, но если вам нравится LINQ, и вы создаете клиенты .NET, WCFDS можно добавить в ваш проект в качестве ссылки на службу. Это позволяет полностью пропустить весь бизнес HTTP и напрямую запросить коллекции.

суть в том, что ничто не мешает вам положить .svc файлы в ваш ASP.Net проект MVC. Это не предложение типа "или-или". Добавление служб data services на сервер избавит вас от необходимости писать много контроллеров, но не помешает вам писать дополнительные контроллеры, если вы хотите.


другими словами :

Если вы хотите, чтобы выставить модель данных (EDM или иначе) быстро и не нужно много кода или бизнес-логики, WCF Data Services делает это очень легко и будет хорошей отправной точкой.

Если вы создаете API и просто хотите предоставить некоторые ресурсы (и логику), используя синтаксис или форматирование запроса OData, то ASP.NET Web API вероятно, лучшее место для начала.

http://mattmilner.com/Milner/Blog/post/2013/04/02/WCF-Data-Services-and-Web-API-with-OData;-choices-choices.aspx


Devaron дал самый информативный обзор WCF vs Web Api, который мне еще предстоит найти. Спасибо. Теперь, когда WCF слишком сложен, я скажу, что сложность не является автоматически отрицательной. Вы будете благодарны за передышку, которую она предоставит вам в будущем. Проблема, как всегда с инструментами Microsoft, заключается в том, что мы не знаем или не контролируем это будущее. Будем надеяться, что Microsoft в конечном итоге получит более унифицированную систему и останется на несколько лет.

Я также есть большая система для создания, и это подчеркивает меня, что путь не более ясен. Я планирую подождать еще пару месяцев, пока все уладится. И лично я болею за datajs (также проверьте JayData)


просто поставьте это таким образом в простейших терминах, отступите от базового протокола и посмотрите на это с точки зрения разработчика/пользователя. Веб-API-это первый класс Microsoft на основе HTTP REST Framework, а не WCF. Это означает, что любые отсутствующие функции Rest, спецификации, они будут добавлены в веб-API-канал и не обязательно в WCF.

Да, вы можете реализовать их самостоятельно в WCF, но, как говорится в предложении, вам нужно реализовать их самостоятельно.

просто в качестве примера сегодня реализация 2-факторной аутентификации для веб-API занимает менее 15 минут, используя OWIN, который является в основном пакетом NuGet аутентификации/авторизации, который начался как проект с открытым исходным кодом.

при использовании стека технологий имеет огромное значение использование стека первого класса для Microsoft. У вас даже будет бесчисленное количество MS опубликованных примеров кода и проектов в Github, которые вы можете просто скопировать и начать работу в своем собственном проекте. Это имеет значение на всех уровень, документация, примеры кода, набор функций, поддержка, вспомогательный api вы называете его.

поэтому мой простой совет вам, если вы хотите построить Restfull HTTP-приложения на основе использования веб-API (или ASP.NET Core для переносимости) и действительно держаться подальше от WCF. Если протокол не HTTP, и он действительно не может быть HTTP, используйте WCF.


Это ответ TL; DR на этот вопрос.

WCF-это швейцарский армейский нож для отвертки WEB API для передачи и передачи данных: WCF может делать все, что может сделать WEB API, но, если вам нужно больше (например, используя протокол TCP), WCF-это путь.

здесь отличное сравнение.

WEB API

причина номер один для использования веб-API заключается в том, что он легкий. Это означает, что проще реализовать, легче учиться, легче поддерживать, и т. д. Он специально разработан для Интернета, который нуждается в веб-службах RESTful через HTTP. Он делает это, и делает это хорошо. Если это все, что вам нужно, веб-API, вероятно,путь.

кроме того, это с открытым исходным кодом (если вы заботитесь)

WCF

WCF просто делает намного больше, чем веб-API: он поддерживает несколько протоколов передачи, несколько шаблонов обмена (веб-API требует интеграции с SignalR или веб-сокетами), службы SOAP могут быть описано в WSDL, имеет дополнительные функции безопасности, и многое другое. Пойдите с WCF, если вам нужна эта дополнительная функциональность.

службы

OData просто

открытый протокол, позволяющий создавать и потреблять queryable и interoperable RESTful API простым и стандартным способом. источник: http://www.odata.org/

другими словами, высокий уровень, это просто стандартизация конкретной грамматики для RESTful запрос http. Что обеспечит те же преимущества, что и любой протокол. И по крайней мере 2013 как WCF, так и WEB API позволяют использовать OData. Так что, вероятно, не стоит беспокоиться об Одате.