Службы данных WCF (OData) по сравнению с веб-API ASP.NET

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

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

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

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

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

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

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

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

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

Во-первых, я не уверен, что ваш босс имел в виду под «MS поддерживает WebApi», имея в виду, что они не поддерживают OData? ИМО, они поддерживают оба, и в настоящее время существует минимальное совпадение. Рынок данных Windows Azure предоставляет свои данные с помощью OData, хранилище таблиц Azure использует OData, SharePoint 2010 позволяет выполнять запросы OData по своим данным, и другие продукты от MS также поддерживают его, например Excel PowerPivot. Когда дело доходит до реляционных данных, это очень мощная среда запросов. А поскольку это RESTful, с ним можно интегрировать любой язык, фреймворк, устройство и т. Д.

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

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

Это похоже на раскрытие "TRANSACT SQL" без необходимости в строке подключения к БД. Просто укажите URL-адрес и все! Начать запросы. Конечно, и WebApi, и WCF Data Services поддерживают аутентификацию / авторизацию, поэтому вы можете контролировать доступ, добавлять дополнительные операторы «Где» на основе ролей или другой конфигурации данных. Я бы предпочел сделать это на своем уровне веб-API, чем в SQL (например, создание представлений или хранимых процедур). И теперь, когда приложения могут сами создавать запросы, вы увидите, как инструменты Ad-Hoc и BI Reporting начинают использовать OData и позволяют пользователям определять свои собственные результаты. Не полагаться на статические отчеты, где у них минимальный контроль.

При разработке в Silverlight, Windows 8 Metro или ASP.NET (MVC, WebForms и т. Д.) Вы можете просто добавить «ссылку на службу» в Visual Studio в службу данных WCF и быстро начать использовать LINQ для запроса данных, и вы получите «Контекст данных» на клиенте, что означает, что он отслеживает изменения и позволяет вам атомарно «отправлять» свои изменения обратно на сервер. Это очень похоже на службы RIA для Silverlight. Я бы использовал WCF Data Services вместо RIA Services, но в то время он не поддерживал DataAnnotations или Actions, а теперь поддерживает :) WCF Data Services имеет еще одно преимущество перед RIA Services, а именно возможность выполнять «проекции» от Клиента. Это может помочь с производительностью, если я не хочу возвращать все свойства объекта. Наличие «контекста данных»

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

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

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

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

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

На данный момент (насколько я понимаю) на клиенте нет поддержки «контекста данных» (например, Silverlight, серверный код ASP.NET и т. Д.), Потому что WebApi на самом деле не касается моделей данных сущностей, таких как службы данных WCF / OData. является. Он может предоставлять коллекции объектов модели с помощью IQueryable / IEnumerable, но нет «свойств навигации» первичного ключа / внешнего ключа (т.е. customer.Invoices) для использования после загрузки объектов на клиенте, потому что нет «контекста данных» который загружает их асинхронно (или за один вызов с помощью $ expand) и управляет изменениями. У вас нет генерируемого кодом «представления» вашей модели данных сущности на клиенте, как в службах RIA или службах данных WCF. Я не говорю, что у вас не может / нет моделей в клиенте, которые представляют ваши данные, но вы вручную заполняете Данные и управляете тем, какие «счета-фактуры» должны выставляться каждому «клиенту» после их получения через Интернет. Это может быть сложно, особенно со всем, что происходит с Async. Вы не знаете, какие звонки вернутся в первую очередь. Здесь это может быть трудно объяснить, но просто прочтите о «контексте данных» в службах RIA илиСлужбы данных WCF . Так что при работе с Line of Business Apps это главная проблема для меня. В основном это основано на производительности и ремонтопригодности. Вы можете бессмысленно создавать приложения без контекста данных. Это просто упрощает работу, особенно в 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 в JavaScript также может стать доступным, что сделает возможность запросов к службам OData еще проще из JavaScript (сегодня вы можете использовать DataJS с OData). Кроме того, использование KnockoutJS для поддержки MVVM и Binding в HTML / JS сделает это проще простого :)

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

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

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

Блог команды OData

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

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

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

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

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

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

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

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

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

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

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

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

Так же, как пример, который сегодня реализует двухфакторную аутентификацию для веб-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

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

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

WCF

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

OData

OData - это просто

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

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