Attualmente ci sono altre grandi differenze tra WebApi e WCF Data Services, che nessuno sembra mai menzionare. Vorrei che MS uscisse con un buon articolo che confronta i due.
Seguo OData da un po 'e anche WebApi. Ho sempre trovato alcune importanti distinzioni.
Innanzitutto, non sono sicuro di cosa intenda il tuo capo con "MS sta supportando WebApi", nel senso che non stanno supportando OData ?? IMO, stanno sostenendo entrambi e attualmente c'è una minima sovrapposizione. Windows Azure Data Market espone i propri dati utilizzando OData, Azure Table Storage utilizza OData, SharePoint 2010 consente query OData sui suoi dati e anche altri prodotti di MS lo supportano, come Excel PowerPivot. È un framework di query molto potente quando si tratta di dati relazionali. E poiché è RESTful, qualsiasi linguaggio, framework, dispositivo, ecc. Può integrarsi con esso.
Ecco cosa mi piace di OData + WCF Data Services:
OData + WCF Data Services ha finalmente consentito alle applicazioni client di essere più "espressive" durante le query sui dati sul Web. Prima, dovevamo sempre utilizzare ASMX o WCF per creare API Web rigide che diventano poco maneggevoli e richiedono modifiche costanti ogni volta che un'interfaccia utente desidera qualcosa di leggermente diverso. L'applicazione client poteva solo specificare parametri per stabilire quali criteri restituire. Oppure fai come ho fatto io e "Serializza" le espressioni LINQ e passale come parametri e reidratati Expressions<Func<T,bool>>sul server. È decente. Ho completato il lavoro, ma desidero utilizzare LINQ sul client e tradurlo sul Web utilizzando REST, che è esattamente ciò che consente OData e non voglio utilizzare il mio "hack" di una soluzione.
È come esporre "TRANSACT SQL" senza la necessità di una stringa di connessione DB. Fornisci semplicemente un URL e whoala! Inizia a interrogare. Naturalmente, sia WebApi che WCF Data Services supportano l'autenticazione / autorizzazione, quindi puoi controllare l'accesso, aggiungere ulteriori istruzioni "Where" in base ai ruoli o ad altre configurazioni dei dati. Preferisco farlo nel mio Web Api Layer che in SQL (come la creazione di viste o Processi archiviati). E ora che le applicazioni possono creare da sole le query, vedrai che gli strumenti di reportistica ad hoc e BI iniziano a sfruttare OData e consentono agli utenti di definire i propri risultati. Non fare affidamento sui rapporti statici in cui hanno un controllo minimo.
Quando si sviluppa in Silverlight, Windows 8 Metro o ASP.NET (MVC, WebForms, ecc.), È possibile aggiungere semplicemente un "Riferimento al servizio" in Visual Studio al WCF Data Service e iniziare rapidamente a utilizzare LINQ per eseguire query sui dati E si ottiene un "Data Context" sul client, il che significa che tiene traccia delle modifiche e consente di "inviare" le modifiche in modo atomico al server. Questo è molto simile a RIA Services per Silverlight. Avrei usato WCF Data Services invece di RIA Services, ma all'epoca non supportava DataAnnotations o Actions, ma ora lo fa :) WCF Data Services ha un altro vantaggio rispetto a RIA Services, ovvero la capacità di eseguire "proiezioni" dal Cliente. Questo può aiutare con le prestazioni, nel caso in cui non voglio restituire tutte le proprietà da un'entità. Avere un "contesto dei dati"
Pertanto, WCF Data Services è ottimo se si dispone di dati con relazioni, soprattutto se si utilizzano SQL Server ed Entity Framework. Sarai rapidamente in grado di esporre dati interrogabili + azioni (chiamate per richiamare operazioni, ad esempio flussi di lavoro, processi in background) su REST con pochissimo codice. WCF Data Services è stato appena aggiornato. Lanciata una nuova versione. Scopri tutte le nuove funzionalità.
Lo svantaggio di WCF Data Services è il "controllo" che si perde sullo Stack HTTP. Ho scoperto che il difetto più grande era nei IQueryable<T>metodi che restituiscono le raccolte. A differenza dei servizi RIA E WebApi, NON hai pieno accesso per sviluppare la logica nel metodo IQueryable. In RIA Services e WebApi, puoi scrivere qualsiasi codice desideri finché ritorni IQueryable<T>. In WCF Data Services, puoi SOLO accedere per aggiungere un'istruzione "Where" utilizzandoExpression<Func<T,bool>> metodi di intercettazione. L'ho trovato deludente. La nostra attuale applicazione utilizza i servizi RIA e trovo che abbiamo davvero bisogno della capacità di controllare la logica IQueryable. Spero di sbagliarmi su questo e mi manca qualcosa
Inoltre, WCF Data Services NON supporta ancora completamente tutti gli operatori LINQ. Tuttavia, supporta ancora più di WebApi.
Che mi dici di WebApi ???
- Mi piace il controllo su Http Request / Response
- È facile da seguire (sfruttando i modelli MVC). Sono sicuro che arriveranno altri strumenti.
A partire da ora (per quanto ne so), non esiste alcun supporto "Data Context" sul client (ad esempio Silverlight, ASP.NET Server-Side Code, ecc.), Perché WebApi non riguarda realmente i modelli di dati di entità come WCF Data Services / OData è. Può esporre collezioni di oggetti modello utilizzando IQueryable / IEnumerable, ma non ci sono "Proprietà di navigazione" chiave primaria / chiave esterna (es. Cliente.Invoices) da utilizzare una volta caricate le entità sul client, perché non esiste un "contesto dati" che li carica in modo asincrono (o in una chiamata utilizzando $ expand) e gestisce le modifiche. Non hai una "rappresentazione" generata dal codice del tuo Entity Data Model sul client, come fai in RIA Services o WCF Data Services. Non sto dicendo che non puoi / non hai Modelli nel Cliente che rappresentano i tuoi Dati, ma devi compilare manualmente i Dati e gestire quali "fatture" devono essere impostate con ciascun "cliente" una volta recuperate sul Web. Questo può diventare complicato, specialmente con tutte le cose Async in corso. Non sai quali chiamate verranno richiamate per prime. Questo può essere difficile da spiegare qui, ma leggi solo le informazioni sul "contesto dei dati" in RIA Services oServizi dati WCF . Quindi, quando si tratta di app Line of Business, questo è un problema importante per me. Ciò si basa principalmente sulla produttività e sulla manutenibilità. Puoi creare obsolete app senza un contesto dati. Semplifica semplicemente le cose, specialmente in Silverlight, WPF e ora in Windows 8 Metro. Avere entità relazionali caricate in memoria in modo asincrono e avere Two-Binding è davvero bello da avere.
Detto questo, questo significa che un giorno WebApi potrà supportare un "Data Context" sul client? Penso che potrebbe. Inoltre, con più strumenti, un progetto Visual Studio potrebbe generare tutti i metodi CRUD basati su uno schema di database (o Entity Framework).
Inoltre, so di menzionare solo .NET in .NET Frameworks quando si tratta di lavorare con WCF Data Services o WebApi, ma sono ben consapevole che HTML / JS è anche un attore importante. Stavo solo menzionando i vantaggi che ho riscontrato quando ho a che fare con un'interfaccia utente Silverlight, o un codice lato server ASP.NET, ecc. Credo che con l'avvento di "IndexedDB" in HTML5 / JavaScript che avere un "Contesto dati" e un Potrebbe anche diventare disponibile il framework LINQ in JavaScript, rendendo la capacità di eseguire query sui servizi OData ancora più semplice da JavaScript (oggi è possibile utilizzare DataJS con OData). Inoltre, l'utilizzo di KnockoutJS per supportare MVVM e Binding in HTML / JS lo renderà un gioco da ragazzi :)
Attualmente sto cercando quale piattaforma utilizzare. Sarei felice di utilizzare entrambi, ma tendo a propendere per OData in base al fatto che la mia prossima applicazione riguarda principalmente Analytics (sola lettura) e voglio una ricca API RESTful espressiva. Credo che OData + WCF Data Services me lo dia perché WebApi supporta solo $ take, $ skip, $ filter, $ orderby su Collections. NON supporta proiezioni, include ($ expand), ecc. Non ho molti "aggiornamenti / eliminazioni / inserimenti" ei nostri dati sono abbastanza relazionali.
Spero che altri si uniranno alla discussione e daranno i loro pensieri. Sto ancora decidendo e mi piacerebbe sentire altre opinioni. Penso davvero che entrambi i framework siano fantastici. Mi chiedo se devi anche solo scegliere, perché non usarli entrambi se necessario. Dal client si tratta comunque di creare chiamate REST. Solo un pensiero :)