В даний час існують інші основні відмінності між WebApi та WCF Data Services, про які ніхто ніколи не згадує. Я хотів би, щоб МС вийшов з гарною статтею, в якій би порівнювали ці два.
Я деякий час стежив за OData, а також за WebApi. Я завжди знаходив кілька основних відмінностей.
По-перше, я не впевнений, що ваш бос має на увазі під "MS підтримує WebApi", тобто, що вони не підтримують OData ?? ІМО, вони підтримують обидва, і в даний час існує деяке мінімальне перекриття. Ринок даних Windows Azure виставляє свої дані за допомогою OData, сховище таблиць Azure використовує OData, SharePoint 2010 дозволяє запити OData над своїми даними, а інші продукти від MS також підтримують це, наприклад Excel PowerPivot. Це дуже потужний фреймворк запитів, коли справа стосується реляційних даних. І оскільки це RESTful, будь-яка мова, фреймворк, пристрій тощо може інтегруватися з ним.
Ось що мені подобається в службах даних OData + WCF:
Служби даних OData + WCF нарешті дозволили клієнтським програмам бути більш виразними при запитах даних через Інтернет. Раніше нам завжди доводилося використовувати ASMX або WCF для створення жорстких веб-інтерфейсів, які отримують незграбність і вимагають постійних змін, коли користувальницький інтерфейс хоче щось інше. Клієнтська програма могла вказати лише параметри, які визначають, які критерії повертати. Або зробіть так, як я, і "Серіалізуйте" вираз LINQ і передайте їх як Параметри та повторно гідратуйте Expressions<Func<T,bool>>на Сервер. Це гідно. Зробив роботу, але я хочу використовувати LINQ на Клієнті і перекласти її через Інтернет за допомогою REST, що саме дозволяє OData, і я не хочу використовувати свій власний "хак" рішення.
Це як викриття "TRANSACT SQL" без необхідності рядка підключення до БД. Просто надайте url і whoala! Почніть запитувати. Звичайно, і WebApi, і WCF Data Services підтримують автентифікацію / авторизацію, тому ви можете контролювати доступ, додавати додаткові оператори "Де" на основі ролей чи іншої конфігурації даних. Я вважаю за краще робити це в моєму шарі Web Api, ніж у SQL (наприклад, будувати подання або збережені документи). І тепер, коли Програми можуть самостійно створювати запити, ви побачите спеціальні інструменти звітування та BI, які починають використовувати OData і дозволяють Користувачам визначати власні результати. Не покладаючись на статичні звіти, де вони мають мінімальний контроль.
При розробці в Silverlight, Windows 8 Metro або ASP.NET (MVC, WebForms тощо) ви можете просто додати "Посилання на послуги" у Visual Studio до служби даних WCF і швидко почати використовувати LINQ для запиту даних І ви отримаєте "Контекст даних" на Клієнті, що означає, що він відстежує зміни і дозволяє "Атомно подавати" свої зміни назад на Сервер. Це дуже схоже на Служби RIA для Silverlight. Я б використовував WCF Data Services замість RIA Services, але на той час він не підтримував DataAnnotations або Action, але зараз підтримує :) WCF Data Services має ще одну перевагу перед RIA Services, а саме можливість виконувати "Проекції" від Клієнта. Це може допомогти з підвищенням продуктивності, якщо я не хочу повертати всі властивості від сутності. Наявність "контексту даних"
Отже, WCF Data Services чудово підходить, якщо у вас є дані зі зв’язками, особливо якщо ви використовуєте SQL Server та Entity Framework. Ви швидко зможете виставити "Дані, що вимагаються" + дії (виклики для виклику операцій, тобто робочих процесів, фонових процесів) через REST з дуже невеликим кодом. Служби даних WCF щойно оновили. Запущено новий випуск. Перевірте всі нові функції.
Недоліком WCF Data Services є «контроль», який ви втрачаєте над стеком HTTP. Я знайшов найбільший недолік у IQueryable<T>Методах, які повертають Колекції. На відміну від RIA Services AND 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 Data Services / OData є. Він може виставляти Колекції об’єктів моделі за допомогою IQueryable / IEnumerable, але не існує первинного ключа / зовнішнього ключа «Властивості навігації» (тобто customer.Invoices) для використання після завантаження Суб’єктів на Клієнта, оскільки немає «Контексту даних» який завантажує їх асинхронно (або в одному дзвінку за допомогою $ expand) та керує змінами. У вас немає генерованого кодом "представлення" вашої моделі даних сутності на клієнті, як у RIA Services або WCF Data Services. Я не кажу, що ви не можете / не маєте моделей у клієнті, які представляють ваші дані, але ви вручну заповнюєте Дані та керуєте тим, які "рахунки-фактури" слід встановлювати кожному "клієнту" після їх отримання через Інтернет. Це може бути складно, особливо з усіма матеріалами Async. Ви не знаєте, які дзвінки повернуться першими. Це може бути важко пояснити тут, але просто прочитайте про "Контекст даних" у RIA Services абоСлужби даних WCF . Отже, коли я маю справу з додатками для бізнесу, це є головним питанням для мене. Це в основному базується на продуктивності та ремонтопридатності. Ви можете спокійно створювати додатки без контексту даних. Це просто полегшує роботу, особливо в 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 ще простішою з JavaScript (ви можете використовувати DataJS сьогодні з OData). Крім того, використання KnockoutJS для підтримки MVVM та Binding в HTML / JS також зробить це легким :)
Зараз я досліджую, яку платформу використовувати. Я був би радий використовувати будь-яку з них, але я схиляюся до OData, виходячи з того, що моя наступна Програма стосується переважно Analytics (лише для читання), і я хочу насичений виразний RESTful Api. Я вважаю, що OData + WCF Data Services дають мені це, оскільки WebApi підтримує лише $ take, $ skip, $ filter, $ orderby над колекціями. Він НЕ підтримує Проекції, Включає ($ розширити) і т. Д. У мене не так багато "Оновлення / Видалення / Вставки", і наші Дані досить реляційні.
Сподіваюсь, інші люди приєднаються до обговорення та висловлять свої думки. Я все ще приймаю рішення і хотів би почути інші думки. Я справді думаю, що обидва ці рамки є чудовими. Цікаво, якщо вам навіть доводиться вибирати, чому б не використовувати обидва, якщо це потрібно. Від Клієнта все одно полягає у створенні дзвінків REST. Просто думка :)