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

Ответ 1

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

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

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

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

Ответ 2

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

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

Во-первых, я не уверен, что ваш босс означает, что "MS поддерживает WebApi", поскольку означает, что они не поддерживают OData?? ИМО, они поддерживают оба варианта, и в настоящее время существует некоторое минимальное перекрытие. Windows Azure Data Market предоставляет свои данные с использованием OData, Azure Table Storage использует OData, SharePoint 2010 позволяет OData Queries над ним Data и другие продукты от MS также поддерживают его, например Excel PowerPivot. Это очень мощная структура запросов, когда дело доходит до реляционных данных. И поскольку он RESTful, любой язык, инфраструктура, устройство и т.д. Могут интегрироваться с ним.

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

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

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

При разработке в Silverlight, Windows 8 Metro или ASP.NET(MVC, WebForms и т.д.) вы можете просто добавить "Сервисную ссылку" в Visual Studio в службу данных WCF и быстро начать использовать LINQ для запроса данных AND вы получаете "Контекст данных" на клиенте, что означает, что он отслеживает изменения и позволяет "отправить" ваши изменения в физическом порядке обратно на Сервер. Это очень похоже на RIA Services для Silverlight. Я бы использовал службы данных WCF вместо RIA Services, но в то время он не поддерживал DataAnnotations или Actions, но теперь это происходит:) У служб данных WCF есть еще одно преимущество перед службами RIA, что позволяет выполнять "Прогнозы", от Клиента. Это может помочь в производительности, если я не хочу возвращать все свойства из объекта. Наличие "Контекста данных" на клиенте замечательно при работе с приложениями Line-Of-Business.

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

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

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

Как насчет WebApi???

• Мне нравится контроль над Http Request/Response
• Легко следовать (используя шаблоны MVC). Я уверен, что больше инструментов появится.

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

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

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

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

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

Ответ 3

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

Блог группы OData

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

Ответ 4

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

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

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

Ответ 5

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

Если вы хотите быстро найти модель данных (EDM или иначе) и не нуждаетесь в большом количестве кода или бизнес-логики, службы данных WCF делают это ДЕЙСТВИТЕЛЬНО легким и будут хорошей отправной точкой,

Если вы создаете 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

Ответ 6

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

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

Ответ 7

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

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

Вот отличное сравнение.

WEB API

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

Кроме того, это Open Source (если вам интересно)

WCF

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

OData​​h2 >

OData просто

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

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

Ответ 8

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

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

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

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

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