Où en sont les services WCF et ADO.Net Data ?

Question

Je suis un peu confus au sujet des services de données ADO.Net.

Est-il uniquement destiné à créer des services Web RESTful ?Je sais que WCF a commencé dans le monde SOAP, mais j'entends maintenant qu'il prend bien en charge REST.Il en va de même pour les services de données ADO.Net où vous pouvez les faire fonctionner dans un modèle RPC si vous ne pouvez pas tout regarder d'un point de vue orienté ressources.

Au moins d'après les démos que j'ai vues récemment, il semble qu'ADO.Net Data Services soit construit sur la pile WCF sur le serveur.S'il vous plait corrigez moi si je me trompe.

Je n'ai pas l'intention de lancer un débat REST vs SOAP, mais je suppose que les choses ne sont plus aussi claires.

Des suggestions ou des directives sur ce qu'il faut utiliser et où ?

Answer 1

À mon avis, les services de données ADO.Net servent à créer des services reposants étroitement alignés sur votre modèle de domaine, c'est-à-dire que les modèles eux-mêmes sont publiés plutôt que de dire une forme de DTO, etc.

L'utiliser pour des services de style RPC semble être une mauvaise solution, même si malheureusement même certaines fonctionnalités très basiques comme la possibilité d'effectuer des décomptes filtrés, etc.ne sont pas disponibles, ce qui signifie souvent que vous finirez par utiliser certains RPC uniquement pour répondre aux exigences de vos clients, c'est-à-direafin que vous puissiez afficher une grille paginée, etc.

WCF 3.5 pré-SP1 était une plate-forme RESTful assez faible, avec le SP1, les choses se sont améliorées à la fois dans les modèles Uri et avec la disponibilité du support ATOMPub, de sorte qu'il devient plus performant, mais ils ne fournissent pas vraiment de solution élégante pour prendre en charge, par exemple, JSON , XML, ATOM ou même quelque chose de plus ésotérique comme une charge utile comme CSV simultanément, sans avoir à utiliser la réécriture d'URL et différentes extensions, la munging du nom de méthode, etc.- plutôt que de simplement sélectionner un sérialiseur/désérialiseur en fonction des en-têtes de la requête.

Avec WCF, il est toujours difficile de créer des services qui fonctionnent de manière plus naturelle et reposante, c'est-à-direoù les ressources incluent des URL, et vous pouvez changer d'état en les parcourant - c'est un peu maladroit - les services de données ADO.Net le font assez bien avec leur prise en charge AtomPub.

Ma recommandation serait d'utiliser des services Web là où ils sont naturellement des services et des limites de service strictes sont appliquées, d'utiliser les services ADO.Net Data pour les clients riches de style Web (sites Web, ajax, silverlight) où la composabilité des requêtes d'URL peut enregistrer un beaucoup de plomberie et votre modèle de domaine est assez basique...et lancez votre propre couche REST (peut-être en utilisant un framework MVC comme point de départ) si vous avez besoin d'un contrôle complet sur les informations, c'est-à-diresi vous publiez une API pour que d'autres développeurs puissent la consommer sur une plateforme sociale, etc.

Ma valeur de 2ø !

Answer 2

L'utilisation de la liaison rest de WCF est très valable lorsque vous travaillez avec du code qui n'interagit pas du tout avec une base de données.Les verbes HTTP ne doivent pas toujours aller à l'encontre d'un fournisseur de données.

Answer 3

En fait, il existe des options pour filtrer et ignorer pour obtenir la fonctionnalité de type page, entre autres.

Vois ici: