Il existe d'autres différences majeures entre WebApi et des Services de Données WCF, dont personne ne semble en parler. Je souhaite MS de sortir avec un bon article qui compare les deux.
J'ai suivi OData pour un certain temps et aussi WebApi. J'ai toujours trouvé un peu de distinctions importantes.
Tout d'abord, je ne suis pas sûr de ce que votre patron entend par "MS est la sauvegarde de WebApi", comme pour dire qu'ils ne sont pas la sauvegarde OData?? L'OMI, ils sont la sauvegarde à la fois et actuellement il y a un certain chevauchement. Marché de Données Windows Azure expose leurs Données à l'aide de OData, Azure Table Storage utilise OData, SharePoint 2010 permet OData des Requêtes sur des Données, et d'autres Produits à partir de MS sont également soutien, tels que Excel, PowerPivot. C'est un très puissant Requête cadre quand il s'agit de Données relationnelles. Et parce que c'est Reposant, de toute langue, de cadre, de l'appareil, etc peut s'intégrer à elle.
Voici ce que j'aime à propos de OData + WCF Data Services:
OData + WCF Data Services a finalement permis d'Applications Client à être plus "expressive" lors de l'interrogation des Données sur le Web. Avant, nous avons toujours eu à utiliser ASMX ou WCF pour construire rigide Api Web qui obtiennent difficile et exiger des changements constants à chaque fois qu'une INTERFACE utilisateur veut quelque chose de légèrement différent. L'Application Cliente ne pouvait spécifier les paramètres de dicter ce que les critères de rendement. Ou faire comme moi et de "Sérialiser" Expressions LINQ et passer tous ces Paramètres et ré-hydrater en Expressions<Func<T,bool>> sur le Serveur. Son décent. Fait le travail, mais je veux l'utiliser LINQ sur le Client et les traduire sur le Web à l'aide de REPOS, ce qui est exactement ce que OData permet et je ne veux pas utiliser mon propre "hack" de la solution.
C'est comme l'exposition "TRANSACT SQL", sans la nécessité d'un DB de la Chaîne de Connexion. Simplement fournir une Url et whoala! Commencer à interroger. Bien sûr, les deux WebApi et des Services de Données WCF en charge l'Authentification/Autorisation, de sorte que vous pouvez contrôler l'accès, ajouter des "Où" les états basés sur les rôles ou d'autres données de configuration. Je préfère le faire dans mon Api Web Couche que dans SQL (comme la construction de points de Vue ou Stockées Procs). Et maintenant que les Applications peuvent créer des requêtes elles-mêmes, vous verrez Ad-Hoc et de business intelligence outils de Reporting, commence à mobiliser OData et permettre aux Utilisateurs de définir leurs propres résultats. En ne s'appuyant pas sur des Rapports Statiques où ils ont peu de contrôle.
Lors de l'élaboration de Silverlight, Windows 8 Metro, ou ASP.NET (MVC, WebForms, etc), vous pouvez simplement ajouter un "Service de Référence" dans Visual Studio pour le Service de Données WCF et commencer rapidement à l'aide de LINQ to de Données de requête ET vous obtenez un "Contexte de Données sur le Client, ce qui signifie qu'il enregistre les changements et vous permet de vous "Présenter" vos modifications automatiquement vers le Serveur. Cette très similaire à RIA Services pour Silverlight. Je l'aurais utilisé les Services de Données WCF au lieu de RIA Services, mais à l'époque, il n'a pas de soutien DataAnnotations ou d'Actions, mais maintenant c'est fait :) les Services de Données WCF a un autre avantage sur les RIA Services, qui est la capacité à effectuer des "Projections" de la part du Client. Cela peut aider à la performance, au cas où je ne veux pas retourner toutes les Propriétés d'une Entité. Avoir un "Contexte de Données sur le Client est idéal lorsque vous traitez avec Des Applications métiers.
Ainsi, les Services de Données WCF est idéal si vous avez des Données avec les relations, surtout si vous utilisez SQL Server et Entity Framework. Vous serez rapidement en mesure d'exposer Queryable de Données + Actions (appels d'invoquer des opérations, c'est à dire des flux de travail, les processus d'arrière-plan) sur le REPOS avec très peu de Code. Les Services de Données WCF a été juste mis à jour. Nouvelle version lancée. Découvrez toutes les nouvelles fonctionnalités.
Le revers de la médaille pour les Services de Données WCF est le "contrôle" vous lâche plus de la Pile HTTP. J'ai trouvé le plus gros défaut était dans l' IQueryable<T> Méthodes qui renvoient des Collections. Contrairement à RIA Services ET WebApi, vous N'avez PAS un accès complet à développer la logique de l'IQueryable Méthode. Dans RIA Services et WebApi, vous pouvez écrire le code que vous voulez aussi longtemps que vous revenez IQueryable<T>. Dans les Services de Données WCF, il vous suffit d'accéder à ajouter un "Où" Énoncé à l'aide de Expression<Func<T,bool>> intercepteur Méthodes. J'ai trouvé cela décevant. Actuellement, notre application utilise les Services RIA et je trouve que nous avons vraiment besoin de la capacité à contrôler le IQueryable logique. J'espère que je me trompe sur ce point et je suis juste en manque de quelque chose
Aussi, les Services de Données WCF n'a PAS encore pleinement à tous les Opérateurs LINQ. Il prend toujours en charge de plus de WebApi.
Qu'en est WebApi???
- J'aime le contrôle sur Requête/Réponse Http
- Il est facile à suivre (effet de levier motifs MVC). Je suis sûr que d'autres l'outillage qui va venir.
Dès maintenant (à ma connaissance), il n'y a pas de "Contexte de Données" soutenir le Client (c'est à dire Silverlight, ASP.NET le Code Côté Serveur, etc), parce que WebApi n'est pas vraiment à propos de Modèles de Données d'Entité, comme les Services de Données WCF/OData est. Il expose des Collections d'Objets de Modèle à l'aide de IQueryable/IEnumerable, mais il n'y a pas de Clé Primaire/Clé Étrangère "Propriétés de Navigation" (par exemple le client.Les factures) à utiliser une fois que les Entités sont chargées sur le Client, car il n'existe pas de Données de Contexte" qui les charge de manière asynchrone (ou dans un appel à l'aide de $expand), et gère les changements. Vous n'avez pas de code généré de la "représentation" de votre Modèle de Données d'Entité sur le Client, comme vous le faites dans RIA Services ou des Services de Données WCF. Je ne dis pas que vous ne pouvez pas/n'ont pas de Modèles dans le Client qui représentent vos Données, mais vous devez remplir manuellement les Données et de gérer les factures sont à régler à chaque "client" une fois qu'ils sont récupérées sur le Web. Cela peut devenir difficile, spécialement avec tous les Async choses qui se passent. Vous ne savez pas qui appelle reviendra première. Ceci peut être difficile à expliquer ici, mais viens de lire sur le "Contexte de Données" choses", RIA Services ou des Services de Données WCF. Quand on parle de la Ligne d'Applications d'Entreprise, c'est un grand problème pour moi. Cela est principalement basée sur la productivité et la facilité de maintenance. Vous pouvez obsolulately de créer des Applications sans un Contexte de Données. Il rend juste les choses plus faciles, spécialement dans Silverlight, WPF, et maintenant Windows 8 Metro. Ayant relationnel Entités chargées dans la mémoire de manière asynchrone et avoir Deux de Liaison est vraiment agréable d'avoir.
Cela dit, est-ce à dire quelques jours WebApi peut prendre en charge un "Contexte de Données sur le Client? Je pense qu'il pourrait. Aussi, avec plus d'outillage, un Projet Visual Studio pourrait générer toutes vos Méthodes CRUD basé sur un Schéma de Base de données (ou Entity Framework).
Aussi, je sais que je suis le seul fait de mentionner .NET pour .NET Cadres quand il s'agit de travailler avec les Services de Données WCF ou WebApi, mais je suis très conscient que HTML/JS est également un acteur majeur. Je viens de mentionner les avantages que j'ai trouvé lorsque vous traitez avec une INTERFACE utilisateur Silverlight, ou ASP.NET le Code Côté Serveur, etc. Je crois qu'avec l'avènement de la "IndexedDB" en HTML5/JavaScript, que le fait d'avoir un "Contexte de Données" et une LINQ cadre en JavaScript peuvent également devenus disponibles, ce qui rend la possibilité d'interroger les Services OData encore plus facile à partir de JavaScript (vous pouvez utiliser DataJS aujourd'hui avec OData). De Plus, à l'aide de KnockoutJS à l'appui de MVVM et de Liaison en HTML/JS ainsi, il sera un jeu d'enfant :)
Je suis actuellement à la recherche de la plate-forme à utiliser. Je serais heureuse de l'aide, mais j'ai tendance à pencher vers OData basée sur le fait que ma prochaine Demande est essentiellement à propos de google Analytics (en lecture seule) et je veux un riche expressive Api RESTful. Je crois OData + Services de Données WCF me donne que parce que WebApi ne supporte $prendre$, de sauter, filtre$, $orderby sur les Collections. Il ne prend PAS en charge les Projections, Comprend ($expand), etc. Je n'ai pas beaucoup de "Mises à jour/Suppressions/Inserts" et de nos Données est assez relationnel.
J'espère que d'autres vont se joindre à la discussion et de donner à leurs pensées. Je suis toujours décider et je serais ravi d'entendre d'autres opinions. Je pense vraiment que les deux sont des cadres sont grands. Je me demande si vous avez à choisir, pourquoi ne pas utiliser les deux en cas de besoin. À partir du Client, il est tout au sujet de la construction d'appels de REPOS, de toute façon. Juste une pensée :)
