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 fait partie d'une série de traductions d'articles de Brad Abrams sur le développement d'applications métier avec Silverlight 3 et .NET RIA Services.

Retrouvez l'ensemble des articles de la série sur cette page : Exemple d'application métier avec Silverlight 3 et .NET RIA Services.

Commentez cet article : Commentez Donner une note à l'article (5)

Article lu   fois.

Les deux auteurs

Site personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

Traduction

Magasin de données basé sur ADO.NET Data Services

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.

Image non disponible

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) :

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...

Image non disponible

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.

Image non disponible

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.

 
Sélectionnez
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...

Image non disponible

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.

Image non disponible

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 :

 
Sélectionnez
[ReadOnly(true)]
[Key]
public int EmployeeID;
&#160;
[RegularExpression("^(?:m|M|male|Male|f|F|female|Female)$", 
   ErrorMessage = "Gender must be 'Male' or 'Female'")]
public string Gender;
&#160;
[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.

 
Sélectionnez
[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.

 
Sélectionnez
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.

 
Sélectionnez
public void UpdateSuperEmployee(SuperEmployee currentSuperEmployee)
{
   var q = from emp in Context.SuperEmployeeSet
           where emp.EmployeeID == currentSuperEmployee.EmployeeID
               select emp;
&#160;
   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);
}
 
Sélectionnez
public void UpdateSuperEmployee(SuperEmployee currentSuperEmployee)
{
   var q = from emp in Context.SuperEmployeeSet
           where emp.EmployeeID == currentSuperEmployee.EmployeeID
               select emp;
&#160;
   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).

 
Sélectionnez
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.

Image non disponible

Conclusion

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.

Remerciements

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

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2011 Brad Abrams. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC.