La version Code First de Entity Framework est très récente et son utilisation entraine encore quelques opérations manuelles dans la configuration du projet pour un bon fonctionnement avec WCF Data Services.
Ce “tuning” manuel représente une grande partie de l’article et vous pourrez heureusement bientôt vous affranchir de ces étapes.

Les prérequis

- Nous partons du résultat de notre précédent tutoriel dont vous pouvez télécharger les sources ici:

Création du projet WCF Data Services

- Ouvrez la solution CaveAVins.sln dans Visual Studio 2010

- Dans la solution, ajoutez un projet Web de type ASP.Net Empty Web Application appelé CaveAVins.WebApplication

- Ajoutez un nouvel élément Web de type WCF Data Service dans le projet CaveAVins.WebApplication.

Ajout des références

vers WCF Data Services 2011 CTP2

- Le template WCF Data Service qui vient d’être utilisé n’a pas été mis à jour avec la CTP2 et ne pointe donc pas vers les dernières assemblies. Nous allons y remédier manuellement:

- Supprimez les références vers System.Data.Services et System.Data.Services.Client qui sont de version 4:

- Ajoutez manuellement les mêmes assemblies mais de version supérieure qui se trouvent dans C:\Program Files (x86)\WCF Data Services Mar 2011 CTP2\bin\.NETFramework\

vers Entity Framework 4.1

- Supprimez la référence existante à l’assemblie Entity Framework 4.0 pour en ajouter une vers la version 4.1 de Entity Framework

vers le projet CaveAVins.Db

- Ajoutez une référence vers le projet CaveAVins.Db.
C’est dans ce projet que se trouve la couche ORM Entity Framework et dans lequel se trouve la classe DbContext pour notre cave à vins : CaveAVinsContext.

Codage du service WCF Data Services

- Un nouveau service CaveAVinsDataServices.svc a été crée :

- Ouvrez le fichier CaveAVinsDataService.svc.cs

- Il reste à spécifier le contexte Entity Framework sur lequel s’appuyer : c’est à dire la classe définie dans le tutoriel précédent et qui aggrège nos entités Wines et Bottles sur laquelle nous autorisons des accès complets CRUD:

using System;
using System.Collections.Generic;
using System.Data.Services;
using System.Data.Services.Common;
using System.Linq;
using System.ServiceModel.Web;
using System.Web;

namespace CaveAVins.WebApplication
{
    public class CaveAVinsDataService : DataService<CaveAVins.Db.CaveAVinsContext>
    {
        // This method is called only once to initialize service-wide policies.
        public static void InitializeService(DataServiceConfiguration config)
        {
            config.SetEntitySetAccessRule("Wines", EntitySetRights.All);
            config.SetEntitySetAccessRule("Bottles", EntitySetRights.All);
            config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
        }
    }
}

- Il faut également modifier la version de WCF Data Services supportée:

using System;
using System.Collections.Generic;
using System.Data.Services;
using System.Data.Services.Common;
using System.Linq;
using System.ServiceModel.Web;
using System.Web;

namespace CaveAVins.WebApplication
{
    public class CaveAVinsDataService : DataService<CaveAVins.Db.CaveAVinsContext>
    {
        // This method is called only once to initialize service-wide policies.
        public static void InitializeService(DataServiceConfiguration config)
        {
            config.SetEntitySetAccessRule("Wines", EntitySetRights.All);
            config.SetEntitySetAccessRule("Bottles", EntitySetRights.All);
            config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V3;
        }
    }
}

C’est fini !

Testons le service

- Définissez le projet Web comme projet de démarrage.

- Spécifiez le service CaveAVinsDataService.svc comme page de démarrage dans les propriétés Web du projet.

Par défaut, le service est hébergé dans le serveur de développement de Visual Studio.

Lancez l’application.

L’adresse “racine” du service http://localhost:5972/CaveAVinsDataService.svc nous renvoie l’index des collections disponibles.

On peut parcourir les données directement dans le browser web, à partir d’une requête OData sur notre service.

Par-exemple : http://localhost:5972/CaveAVinsDataService.svc/Wines/$count  permet de compter le nombre d’élements de la liste des vins Wines :

Et pour récupérer la liste des vins et leurs propriétés : http://localhost:5972/CaveAVinsDataService.svc/Wines

Dans l’article dédié à l’authentification, nous verrons comment intercepter les requêtes grâce aux Query Interceptors pour adapter nos réponse en fonction de l’utilisateur qui émet la requête.

WCF Data Services va également nous faciliter l’utilisation de ce service côté client .Net, en nous permettant :

- d’ajouter une référence au service et en générant automatiquement les classes proxy correspondant aux types utilisés dans le service.

Pour la petite histoire, c’est grâce au suffixe $metadata (http://localhost:5972/CaveAVinsDataService.svc/$metadata) que cette opération est possible.
En effet, il permet d’obtenir le dictionnaire des entités et associations utilisés dans le service :

- d’utiliser Linq sur les entités, pour spécifier les requêtes qui seront transformées automatiquement en Uri OData par le provider

Vous trouverez un exemple concret de client Silverlight qui exploite un service WCF Data Services dans l’article Tutoriel : Accéder aux listes Sharepoint 2010 par OData en Silverlight.
Dans cet article, les données proviennent de Sharepoint qui propose un accès OData de ses listes et bibliothèques, mais ça ne change rien en ce qui concerne l’exploitation de ce service côté client.

Architecture réalisée à ce stade

Version On Premises

Un service web WCF Data Services permettant de manipuler les données a été mis en place.
Grâce à lui, les données sont accessibles en OData par toute plateforme cliente qui sait communiquer en http et parser du XML : difficile de faire plus interopérable .

Il est temps à présent de faire bon usage de ces données.

Voici les sources à l’issue de ce second tutoriel:

Rendez vous après quelques vacances pour la suite !   

Tutoriels:

- CaveAVins Tutoriel 1 : L’accès aux données avec Sql Server et EF Code First
- CaveAVins Tutoriel 2 : La publication des données en OData avec WCF Data Services (vous êtes ici )
- CaveAVins Tutoriel 3 : Migration d’une base SQL Server vers SQL Azure
- CaveAVins Tutoriel 4 : Hébergement du service WCF Data Services dans Azure

Cet article est le troisième d’une série qui se propose d’introduire les techniques de développement actuelles, dans le cadre d’un besoin et d’un projet concret.
Dans ce volet, nous nous intéressons à la publication des données sur le réseau pour les rendre accessibles à des services ou application clientes.

Notre prétexte métier est un projet de gestion de cave à vins, avec des applications pour le poste de travail et pour Windows Phone.
Retrouvez la description du besoin dans le premier article de la série.

• Développer un projet aujourd’hui : comment faire, par où commencer ?
• Architecture et découpage du projet
• Stockage des données avec Sql Server, EF Code First et Azure 
• La publication des données (vous êtes ici )
• La migration dans Azure
• L’application Windows Phone basique
• Ajout de la fonction d’aide à l’achat 
• Ajout des notifications sur les vins en promotions 

• L’application Silverlight

Et les tutoriels correspondants qui arriveront au fil de l’eau:

- CaveAVins Tutoriel 1 : L’accès aux données avec Sql Server et EF Code First
- CaveAVins Tutoriel 2 : La publication des données en OData avec WCF Data Services (tutoriel correspondant à cet article )
- CaveAVins Tutoriel 3 : Migration d’une base SQL Server vers SQL Azure
- CaveAVins Tutoriel 4 : Hébergement du service WCF Data Services dans Azure

Rappel de l’architecture visée

- L’hébergement des données, des services et applications se fera dans Windows Azure et Sql Azure
- La publication des données sera faite en OData avec WCF Data Services pour rester interopérable avec une grande variété de plateformes clientes
- Les applications clientes seront développées en Silverlight
- Nous nous efforcerons de conserver un maximum de code commun entre les 2 applications grâce à la Portable Library
- Les promotions seront notifiées sur le téléphone par un service de gestion des promotions et des notifications Push

Pour faciliter la mise en pratique de la série de tutoriels, nous commencerons par mettre en place un fonctionnement On Premises (un hébergement sur des serveurs classiques), pour faire migrer la solution plus tard dans Sql Azure. Ainsi, nous obtiendrons un projet qui fonctionnera aussi bien On Premises que dans le Cloud. Cela permettra également de montrer la simplicité avec laquelle des solutions existantes peuvent évoluer vers un hébergement dans Azure.

Choix de la technologie de publication des données

A ce stade, nous avons réalisé le stockage et couche d’accès aux données (mapping ORM).

Pour que les données soient accessibles par des applications clientes, il faut les mettre à disposition sous la forme d’un service. Il y a différentes manières d’effectuer cette opération en fonction des plateformes clientes adressées.
Dans notre cas, nos clients seront:

• des services métiers (services web au sens large)
• une application Silverlight
• une application Silverlight pour Windows Phone
• d’autres applications potentielles à venir, par-exemple en Html5 

Chez Microsoft, les 2 principales technologies de services orientées données sont :

• WCF RIA Services
• WCF Data Services (OData)

WCF RIA Services

En résumé, cette technologie permet de masquer la communication entre le client et le serveur et de reporter automatiquement les règles métiers de validation des données côté client.
C’est une technologie de haut niveau qui améliore la productivité du développement Silverlight puisque les règles métiers ne sont codées qu’une seule fois côté serveur. 

Pour découvrir et comprendre RIA Services, voici quelques articles et vidéos :

• Tutorial Silverlight 4 WCF RIA Services avec 0 ligne de code
• Vidéo : WCF RIA Services de A à Z
• Vidéo : Silverlight 4 en entreprise avec WCF RIA Services

WCF RIA Services est dédié à Silverlight classique uniquement, ce qui exclut son utilisation sur Windows Phone. Mais il offre également des endpoints plus limités de type SOAP, JSON, OData (en lecture seule ) pour laisser la possibilité à d’autres plateformes de consommer les données. Je vous conseille les excellents articles de David sur le sujet : Comment exposer une application WCF RIA Services à d’autres clients ?

WCF Data Services

WCF Data Service est une implémentation pour .Net de OData.
Mais c’est quoi à la fin OData ?
En résumé, cette technologie permet de mettre des données en ligne, de manière très interopérable c’est à dire accessibles de la même manière par toutes sortes de plateformes clientes. 

On bénéficie d’un typage fort des données ainsi que du requêtage à la source.

Par-rapport à WCF RIA Services et en caricaturant, on pourrait dire que l’on troque la productivité contre l’interopérabilité.

Pour notre cave à vins, je préfère utiliser WCF Data Services pour les raisons suivantes:

- Sur mon client WP, je ne peux pas me permettre d’utiliser le endpoint OData de WCF RIA Services, car celui-ci propose un accès aux données en Read Only uniquement . Or j’aurai besoin d’accès en lecture/écriture sur mes données….

- Côté client : je souhaite partager un maximum de code entre les plateformes, ou au moins utiliser une seule technique pour accéder à mes données plutôt que de devoir en apprendre plusieurs.
Or, avec RIA Services, mes clients utiliseront RIA Services lui-même (pour Silverlight), mais aussi les endpoints SOAP, JSON en fonction des plateformes applicatives.

- Côté serveur : si tous mes clients utilisent le même point d’entrée, mon jeu de tests unitaires et fonctionnels en sera réduit d’autant

Ce choix est tout à fait discutable et les arguments sont à mettre en balance avec la productivité apportée par WCF RIA Services. Si notre application principale en Silverlight, était très complète en terme d’accès aux données et que les applications sur devices nomades reprennent simplement quelques vues de synthèse, on pourrait faire un choix différent.

Tout est une question de compromis et le choix se fait en fonction des contraintes, des priorités et des besoins d’évolutivité de votre projet.

Pour aller plus loin, je vous conseille la vidéo de la session dédiée à ce sujet que nous avons présentée aux Techdays avec David Rousset : Choisir une technologie d’accès aux données distantes qui compare WCF, WCF Data Services et WCF RIA Services.

 

WCF Data Services : Comment ça marche ?

A partir de notre couche d’accès aux données Entity Framework (cf article précédent), il est très facile de publier les données au format OData grâce à WCF Data Services.
En effet, WCF Data Services va simplifier le développement côté serveur, en fournissant un template de projet adapté dans Visual Studio et en créant automatiquement le service à partir du contexte de données Entity Framework associé.
Côté client, nous pourrons utiliser ce service très facilement en ajoutant une référence à celui-ci dans Visual Studio, ce qui génère automatiquement les classes proxy incluant le contexte de données.
On exprime ensuite directement des requêtes Linq sur le contexte de données qui seront tranformées automatiquement dans les URIs OData correspondantes, lors de l’exécution.

C’est du charabia ? C’est normal, vous verrez tout cela dans le tutoriel qui vous guidera pas à pas.

Il est noter que WCF Data Services peut tout à fait publier des sources de données autres que Entity Framework comme on peut le voir sur le diagramme suivant:

Avec WCF Data Services, vous pourrez moduler les droits d’accès à vos données en fonction de vos entités (par-exemple, on pourrait imaginer une entité “producteurs” qui serait en lecture seule).
Vous pouvez également aller beaucoup plus loin en définissant des méthodes d’interception des requêtes. Ce mécanisme vous permet d’adapter le résultat de la requête en fonction du contexte ou de règles métier.
On pourra par-exemple faire en sorte que seul l’auteur d’une review ait le droit le la modifier, mais que tout le monde ait le droit de la consulter.

Nous aborderons ce sujet dans l’article consacré à l’authentification avec Access Control Services.

A travers SQL Azure Labs, Sql Azure fournit également une ouverture au format OData de ses données, mais :

• vous zappez la couche ORM faite par Entity et vous obtiendrez donc un mapping 1 classe <-> 1 table
• l’accès aux données est public ou contrôlé par ACS
• vous perdez la possibilité d’intercepter les requêtes pour adapter vous-même les résultats en fonction de l’utilisateur authentifié ou de votre besoin métier

En gros, vous perdez en souplesse, mais vous gagnez en rapidité de développement.

 

La mise en oeuvre

Voici le tutoriel associé pour mettre WCF Data Services en pratique dans le contexte de notre cave à vins.

Au final, nous obtenons un service web qui à partir d’une URI Http (REST) correspondant à une requête CRUD (Create/Read/Update/Delete), effectue l’opération demandée sur les données stockées en base.
Pour une requête de sélection, le service renvoie la collection d’objets résultante sous la forme d’un flux XML (Atom ou JSON).

Nous pouvons donc utiliser un navigateur web comme un client de ce service, et requêter les données directement. 
Ainsi, si l’on tape l’URL du service dans le navigateur : http://localhost:33880/CaveAVinsOData.svc/ on obtient l’index des collections publiées pour notre projet de cave à vins:

 

 

Architecture réalisée à ce stade

Version On Premises

Un service web WCF Data Services a été mis en place. Pour l’instant il est hébergé dans IIS (ou plutôt dans le serveur de test de Visual Studio !).
Grâce à lui, les données sont accessibles en OData par toute plateforme cliente qui sait communiquer en http et parser du XML : difficile de faire plus interopérable .

Version Cloud

Dans la version Cloud à venir, c’est Azure qui hébergera ce service sous la forme d’un web role comme nous le verrons dans l’article consacré à la migration.

En résumé, les différences de la version Cloud sont:

- Base de données Sql Azure au lieu de Sql Server

- Ajout du web role qui permet de configurer l’hébergement du service dans Azure

 

Tout est en place pour permettre la manipulation de ces données à partir de services métiers ou d’applications clientes.

C’est ce que nous verrons un peu de vacances !   

Articles:

• Développer un projet aujourd’hui : comment faire, par où commencer ?
• Architecture et découpage du projet
• Stockage des données avec Sql Server, EF Code First et Azure
• La publication des données (vous êtes ici )
• La migration dans Azure
• L’application Windows Phone basique
• Ajout de la fonction d’aide à l’achat
• Ajout des notifications sur les vins en promotions

• L’application Silverlight

Tutoriels:

- CaveAVins Tutoriel 1 : L’accès aux données avec Sql Server et EF Code First
- CaveAVins Tutoriel 2 : La publication des données en OData avec WCF Data Services (tutoriel correspondant à cet article )
- CaveAVins Tutoriel 3 : Migration d’une base SQL Server vers SQL Azure
- CaveAVins Tutoriel 4 : Hébergement du service WCF Data Services dans Azure