В настоящее время между WebApi и WCF Data Services существуют и другие существенные различия, о которых никто никогда не упоминал.Я бы хотел, чтобы М.С. вышла с хорошей статьей, сравнивающей их.
Я уже некоторое время слежу за OData, а также за WebApi.Я всегда находил несколько главных отличий.
Во-первых, я не уверен, что ваш босс имеет в виду под "MS поддерживает WebApi", поскольку означает, что они не поддерживают OData ??ИМО, они поддерживают оба, и в настоящее время есть некоторое минимальное дублирование.Windows Azure Data Market предоставляет свои данные с использованием 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 и Whoala!Начните запрашивать.Конечно, и WebApi, и WCF Data Services поддерживают аутентификацию / авторизацию, поэтому вы можете контролировать доступ, добавлять дополнительные операторы «Где» на основе ролей или другой конфигурации данных.Я бы предпочел сделать это на уровне моего веб-интерфейса, а не на SQL (например, создание представлений или хранимых процедур).И теперь, когда приложения могут сами создавать запросы, вы увидите, что инструменты Ad-Hoc и BI Reporting начнут использовать OData и позволят пользователям определять свои собственные результаты.Не полагаясь на статические отчеты, где они имеют минимальный контроль.
При разработке в Silverlight, Windows 8 Metro или ASP.NET (MVC, WebForms и т. Д.) Вы можете просто добавить «Справочник по службам» в Visual Studio в службу данных WCF и быстро начать использовать LINQ длязапрашивать данные И вы получаете «контекст данных» на клиенте, что означает, что он отслеживает изменения и позволяет вам «отправить» ваши изменения атомарно обратно на сервер.Это очень похоже на RIA Services для Silverlight.Я бы использовал WCF Data Services вместо RIA Services, но в то время он не поддерживал DataAnnotations или Actions, но теперь это делает :) WCF Data Services имеет еще одно преимущество перед RIA Services, а именно способность выполнять «проекции».от клиента.Это может помочь с производительностью, если я не хочу возвращать все свойства от сущности.Наличие «контекста данных» на клиенте замечательно при работе с бизнес-приложениями.
Итак, службы данных WCF хороши, если у вас есть данные со связями, особенно если вы используете SQL Server и Entity Framework.Вы быстро сможете предоставлять Queryable Data + Actions (вызовы для вызова операций, т. Е. Рабочих процессов, фоновых процессов) поверх REST с очень небольшим количеством кода.Службы данных WCF были только что обновлены.Новый релиз запущен.Проверьте все новые функциональные возможности.
Недостатком WCF Data Services является «контроль», который вы теряете над стеком HTTP.Я обнаружил, что самый большой недостаток был в IQueryable<T> Методах, которые возвращают Коллекции.В отличие от RIA Services и WebApi, вы НЕ имеете полного доступа для разработки логики в методе IQueryable.В RIA Services и WebApi вы можете написать любой код, который хотите, если вы вернете IQueryable<T>.В Службах данных WCF вы ТОЛЬКО получаете доступ для добавления оператора «Где», используя методы перехвата Expression<Func<T,bool>>.Я нашел это разочаровывающим.Наше текущее приложение использует RIA Services, и я считаю, что нам действительно нужна возможность контролировать логику IQueryable.Я надеюсь, что ошибаюсь в этом, и я просто что-то упускаю
Кроме того, WCF Data Services пока еще не полностью поддерживает все операторы LINQ.Тем не менее, он поддерживает больше, чем WebApi.
А как насчет WebApi ???
- Мне нравится контроль над Http-запросом / ответом
- Легко следовать (используяШаблоны MVC).Я уверен, что появится больше инструментов.
На данный момент (насколько я понимаю) не поддерживается «Контекст данных» на клиенте (т. Е. Silverlight, серверный код ASP.NET и т. Д.), потому что WebApi на самом деле не о моделях данных сущностей, таких как WCF Data Services / OData.Он может предоставлять Коллекции Объектов Модели, используя IQueryable / IEnumerable, но нет «Свойства навигации» Первичного ключа / Внешнего ключа (т. Е. Customer.Invoices), которые можно использовать после загрузки сущностей на клиенте, поскольку отсутствует «Контекст данных».который загружает их асинхронно (или за один вызов с использованием $ expand) и управляет изменениями.У вас нет сгенерированного кода «представления» вашей модели данных сущностей на клиенте, как вы это делаете в RIA Services или WCF Data Services.Я не говорю, что у вас не может быть / нет моделей в клиенте, которые представляют ваши данные, но вы вручную заполняете данные и управляете тем, какие «счета-фактуры» должны быть установлены для каждого «клиента» после их получения.паутина.Это может быть сложно, особенно если учесть все, что происходит в Async.Вы не знаете, какие звонки вернутся первыми.Это может быть трудно объяснить здесь, но просто прочитайте о «контексте данных» в RIA Services или WCF Data Services .Поэтому, когда я имею дело с приложениями Line of Business, для меня это большая проблема.Это в основном основано на производительности и ремонтопригодности.Вы можете безоговорочно создавать приложения без контекста данных.Это просто упрощает работу, особенно в Silverlight, WPF, а теперь и в Windows 8 Metro.Наличие реляционных сущностей, загруженных в память асинхронно, и наличие двухсвязывания - это действительно приятно иметь.
Сказав это, означает ли это, что однажды WebApi сможет поддерживать «контекст данных» на клиенте?Я думаю, что мог.Кроме того, с большим количеством инструментов проект Visual Studio может генерировать все ваши методы CRUD на основе схемы базы данных (или Entity Framework).
Кроме того, я знаю, что упоминаю .NET только для .NET Frameworks, когда речь идет о работе с WCF Data Services или 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 для коллекций.Он НЕ поддерживает Проекции, Включает ($ expand) и т. Д. У меня не так много «Обновлений / Удалений / Вставок», и наши Данные довольно реляционные.и высказывать свои мысли.Я все еще решаю и хотел бы услышать другие мнения.Я действительно думаю, что оба являются отличными рамками.Интересно, если вам придется выбирать, почему бы не использовать оба в случае необходимости.От Клиента это все о создании вызовов REST в любом случае.Просто мысль:)