Exemple d'application métier avec Silverlight 3 et .NET RIA Services - Partie 7 : Magasin de données basé sur ADO.NET Data Services

Cet article est la traduction la plus fidèle possible de l'article original de Brad Abrams, Business Apps Example for Silverlight 3 RTM and .NET RIA Services July Update: Part 7: ADO.NET Data Services based Data Store.

Je voulais continuer avec les améliorations apportées à ma présentation Mix09 intitulée « building business applications with Silverlight 3 ». Dans cette section, je vais vous montrer comment obtenir des données de services web basés sur REST plutôt que directement en utilisant Entity Framework ou LINQ to SQL.

Concentrons-nous sur la source de données cloud. Nous allons utiliser le même échantillon des parties précédentes et modifier uniquement la partie accès aux données pour accéder à ADO.NET Data Services comme magasin de données.

Ce modèle pourrait être utile si vous ne contrôlez pas votre base de données directement et devez passer par une couche de services pour y accéder.

La démo requiert les éléments suivants (tout est 100 % gratuit) :

• Visual Studio 2008 Express SP1 (qui comprend SQL Server 2008 Express) ;
• Silverlight 3 ;
• .NET RIA Services.

Vous pouvez, de plus, télécharger les fichiers de la démo complète et jeter un œil à l'application en cours d'exécution.

Démarrez avec le projet MyApp d'une des parties précédentes. Dans le projet de serveur, supprimez les fichiers northwind.mdf et Northwind.edmx.

Ajoutez un nouveau projet à la solution pour contenir le service de données. J'ai utilisé un projet d'application Web ASP.NET et je l'ai appelé MyApp.Service…

Ensuite, ajoutez le fichier Northwind.mdf au dossier app_data de ce nouveau projet et créez un modèle Entity Framework comme nous l'avons montré dans la deuxième partie de cette série.

Maintenant, nous allons ajouter notre service basé sur REST.

Ici nous avons mis en place le DataService pour utiliser le fournisseur EntityFramework, ensuite nous permettons l'accès… remarquez que le « * » est plus une sorte de mode de démonstration, la bonne pratique ici est de lister les tables directement.

public class SuperEmployeeDataService : DataService< NORTHWNDEntities >
{
   public static void InitializeService(IDataServiceConfiguration config)
   {
       config.SetEntitySetAccessRule("*", EntitySetRights.All);
   }
}

Maintenant, nous sommes prêts pour démarrer avec notre service… Pour le tester, définissez-le comme projet de démarrage et appuyez sur F5…

Nous sommes fin prêts à le consommer depuis RIA Services… Remarquez tout ce qui précède est un travail standard d'ADO.NET Data Services… En savoir plus sur ADO.NET Data Services.

Maintenant, entrons dans le vif avec les RIA Services… Retournez au projet Web et ajoutez une référence des services au service que nous venons de créer.

D'abord allons dans SuperEmployeeDomainService.metadata.cs et modifions cette classe pour fonctionner avec notre nouvelle référence. À la base, vous devez juste vous assurer qu'il s'agit d'une classe partielle de la classe proxy SuperEmployee de notre référence de service. Faites cela en changeant l'espace de noms (namespace) à MyApp.Web.SuperEmployeeDataServiceReference. Cette classe vous donne une chance d'ajouter des métadonnées de validation et d'autres informations pour rendre la consommation du client plus propre. Nous validerons ceux-ci sur le client et avant que les données soient réinsérées au service. Quelques exemples :

[ReadOnly(true)]
[Key]
public int EmployeeID;
 
[RegularExpression("^(?:m|M|male|Male|f|F|female|Female)$", 
   ErrorMessage = "Gender must be 'Male' or 'Female'")]
public string Gender;
 
[Range(0, 10000,
   ErrorMessage = "Issues must be between 0 and 1000")]
public Nullable<int> Issues;

Maintenant nous devons faire fonctionner notre SuperEmployeeDomainContext par rapport à ce nouveau service.

[EnableClientAccess()]
public class SuperEmployeeDomainService : DomainService
{
   NORTHWNDEntities Context = new NORTHWNDEntities(
       new Uri("http://localhost:40694/SuperEmployeeDataService.svc/"));

Remarquez ici nous utilisons la classe de base DomainService plutôt que le helper EFDomainService…

Des méthodes telles que GetSuperEmployee () fonctionnent sans aucune modification ! Mais ils vont maintenant passer sur notre service basé sur REST pour accéder à la base de données.

public IQueryable<SuperEmployee> GetSuperEmployees()
{
   return this.Context.SuperEmployeeSet
              .Where(emp=>emp.Issues>100)
              .OrderBy(emp=>emp.EmployeeID);
}

UpdateSuperEmployee a connu un peu plus de modifications, car nous avons besoin de propager les modifications vers les instances que la bibliothèque cliente ADO.NET est en train de suivre.

public void UpdateSuperEmployee(SuperEmployee currentSuperEmployee)
{
   var q = from emp in Context.SuperEmployeeSet
           where emp.EmployeeID == currentSuperEmployee.EmployeeID
               select emp;
 
   var e = q.FirstOrDefault();
   e.Name = currentSuperEmployee.Name;
   e.Gender = currentSuperEmployee.Gender;
   e.Issues = currentSuperEmployee.Issues;
   e.LastEdit = currentSuperEmployee.LastEdit;
   e.Origin = currentSuperEmployee.Origin;
   e.Publishers = currentSuperEmployee.Publishers;
   e.Sites = currentSuperEmployee.Sites;
   
   Context.UpdateObject(e);
}

public void UpdateSuperEmployee(SuperEmployee currentSuperEmployee)
{
   var q = from emp in Context.SuperEmployeeSet
           where emp.EmployeeID == currentSuperEmployee.EmployeeID
               select emp;
 
   var e = q.FirstOrDefault();
   e.Name = currentSuperEmployee.Name;
   e.Gender = currentSuperEmployee.Gender;
   e.Issues = currentSuperEmployee.Issues;
   e.LastEdit = currentSuperEmployee.LastEdit;
   e.Origin = currentSuperEmployee.Origin;
   e.Publishers = currentSuperEmployee.Publishers;
   e.Sites = currentSuperEmployee.Sites;
   
   Context.UpdateObject(e);
}

Enfin, nous avons besoin de surcharger Submit. Ce que cela fait c'est qu'il nous donne la chance d'appeler PersistChangeSet () après que tous les changements dans l'ensemble de modifications aient été traités (l'appel de la méthode de base fait cela).

protected override void PersistChangeSet(ChangeSet changeSet)
{
   base.PersistChangeSet(changeSet);
   this.Context.SaveChanges();
}

Appuyez sur F5 et c'est fait ! Nous avons maintenant exactement la même application, mais avec des données provenant d'un service plutôt que directement d'une base de données.

Remarquez également comment ce fut facile de passer d'un modèle à un autre. C'est une autre raison puissante pour suivre le modèle RIA Services… il vous permet de modifier plus facilement les sources de données back-end sans changer beaucoup de code sur le client.

Cet article conclut donc cette septième partie de cette série d'articles sur le développement d'applications métier avec Silverlight 3 et .NET RIA Services. La huitième partie sera consacrée aux sources de données basées sur WCF.

Je tiens ici à remercier Brad Abrams de nous avoir autorisés à traduire son article.
Je remercie également ClaudeLELOUP pour sa relecture et ses propositions.