В настоящее время существуют другие существенные различия между 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 ???
- Мне нравится контроль над запросом / ответом Http
- За этим легко следить (используя шаблоны 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. Просто мысль :)