Développer une application Silverlight 4 dans Visual Studio 2010

Service à notre application. Celui-ci va nous permettre de générer notre couche métier à partir de la couche d’accès aux données (dans notre cas un ADO.NET Entity Data Model via Entity Framework généré à partir des tables Customers et Orders de la base de données Northwind).

Il suffit de sélectionner les tables que l’on souhaite utiliser dans notre application et le cas échéant de choisir si l’on souhaite pouvoir ou non modifier ces données. La case à cocher « Generate associated classes for metadata » est automatiquement cochée lorsqu’une table est sélectionnée, elle permet de générer les métadonnées correspondantes aux tables et qui pourront servir pour la gestion de contraintes de saisie pour les données par exemple. De plus, il est aussi possible d’exposer ces données via le protocole OData en cochant la case correspondante. Par la suite, un ou deux fichiers (deux si l’on a choisi de générer les classes pour les métadonnées) sont ajoutés à notre solution.

Après l’ajout de notre Domain Service et la compilation de notre solution, on peut remarquer dans l’arborescence de cette dernière (cf. Figure 6), du côté client (Silverlight dans notre cas) qu’un dossier caché a été ajouté se nommant « Generated_Code ». Il possède un fichier qui a été généré contenant la réplication de la couche métier présente du côté serveur. Ce fichier va permettre d’accéder du côté client à toute cette logique métier qui a été mise en place avec notre Domain Service. Si l’on souhaite apporter des modifications, des ajouts à notre couche métier, il est nécessaire de modifier le Domain Service du côté serveur et recompiler notre solution afin de mettre à jour la couche métier du côté client.

Les méthodes générées dans le Domain Service permettent de renvoyer l’ensemble des données d’une table et dans la couche métier d’une application il est plutôt rare de se contenter des données brutes. Il est possible de rajouter ses propres méthodes au Domain Service afin de mieux affiner et/ou trier les ensembles de données à retourner. A noter que toutes les méthodes générées dans le Domain Service retournent des IQueryable, ce qui permet d’utiliser LINQ (Language-Integrated Query) dans nos propres méthodes comme langage de requêtes. De plus lors de la recompilation de la solution, nos propres méthodes seront bien sûr générées elles aussi du côté client.

WCF RIA Services propose les « Authentication Domain Service » qui permettent de simplifier l’accès aux méthodes afin de gérer l’authentification et l’identification d’utilisateurs à une application. Deux types d’authentification sont proposés, l’authentification par formulaire et l’authentification Windows. Tout comme le Domain Service, un fichier est ajouté du côté serveur et est à compléter suivant les besoins de l’application. Lors de la compilation, le code client correspondant est généré et est ajouté dans le même fichier contenant le code généré de notre Domain Service, se trouvant dans le répertoire caché « Generated_Code » (comme expliqué précédemment).

Il est aussi possible d’exposer ses données à travers le réseau grâce à OData. L’Open Data Protocol (OData) permet la création et la transmission de flux de données via le protocole HTTP basé sur une source de données (ORM, base de données relationnelles, fichiers, etc…), et qui va permettre à différents types de clients distants (type RIA, ASP.NET, etc…) d’accéder à ces données et de les exploiter.

Lors de l’utilisation de WCF RIA Service dans une solution, il est possible de demander à exposer les données de notre source de données via OData (cf. Figure 5). Grâce à ce protocole de communication, on pourrait imaginer par la suite de l’exploitation de ces données à la fois avec un client RIA (Rich Internet Application) et une application pour Windows Phone 7 par exemple, c’est-à-dire partager les mêmes données mais avec deux types de périphériques et scénarii d’utilisations différentes.

Pour conclure, WCF RIA Services est un Framework d’aide à la conception d’applications fortement orientées données, qui permet un gain de temps dans le développement et une simplification de la mise en place des mécanismes de communication entre les différentes couches de l’architecture n-tiers d’une application Web. Ce Framework n’est pas encore disponible en version finale mais il apparaît tout de même assez abouti et promet une adoption par un grand nombre de développeurs d’applications RIA (Rich Internent Application) dans les prochains mois.

Pour accéder aux figures associées au dossier, rendez-vous dans le club abonnés.