Silverlight 4 + RIA Services - Prêt pour les affaires

Cet article est la traduction la plus fidèle possible de l'article original de Brad Abrams, Silverlight 4 + RIA Services - Ready for Business: Exposing Data from Entity Framework

Pour continuer notre série, j'ai voulu ensuite regarder la façon d'exposer vos données du côté serveur de votre application.

Les données intéressantes dans vos applications métier proviennent d'une grande variété de sources de données. D'une base de données SQL, d'Oracle DB, de SQL Azure, de SharePoint ou d'un mainframe et vous avez probablement déjà choisi un modèle de données tel que NHibernate, Linq2Sql, Entity Framework, une procédure stockée ou encore un service. Le but de RIA Services dans ce release est de faciliter le travail avec les données d'une ou de plusieurs sources, d'une manière transparente, à partir d'une application Silverlight. Cette procédure pas à pas utilisera Entity Framework pour accéder à la base de données SQL Express, mais le concept de base s'applique à n'importe quelle source de données.

Ajoutez DishView.mdf à BusinessApplication1.Web\App_Data - Bien entendu, dans un exemple réel vous devriez juste avoir une chaîne de connexion à une base de données existante.

Ensuite, créez un modèle Entity Framework au-dessus de celui-ci.

Comme vous pouvez le voir, nous avons un jeu d'entités très simple. Chaque Restaurant peut avoir n'importe quel nombre de Plats.

Ensuite, nous avons besoin de définir une certaine logique métier qui contrôlera et façonnera les données telles qu'elles sont perçues par le client Silverlight. Pour ce faire, nous ajoutons un nouveau DomainService. Un DomainService est simplement un type particulier de service WCF qui rend BEAUCOUP PLUS facile d'interroger, de mettre à jour, de sécuriser et de valider vos données. Mais si vous êtes un expert WCF et connaissez tous les détails pour la configuration d'un service WCF, vous pouvez certainement personnaliser ce service, d'une façon à ce qu'il corresponde exactement à vos besoins. Bien sûr, dans 90% des cas, nous espérons que vous n'aurez pas besoin d'y avoir recours.

Ensuite, il nous est donné la possibilité de pré-remplir le DomainService.

Dans ce cas, nous allons exposer Plat et Restaurant, mais seul Plat pourra être mis à jour. Nous allons également générer une classe de métadonnées pour accrocher les attributs de validation afin que vous puissiez régénérer le modèle EF sans perdre aucune personnalisation. Nous obtenons une classe de démarrage DishViewDomainService. Je l'ai mise à jour aux lignes 8-9 avec un peu de logique métier. Examinons chaque ligne pas à pas...

  1:     [EnableClientAccess]
  2:     public class DishViewDomainService : LinqToEntitiesDomainService<DishViewEntities>
  3:     {
  4: 
  5:         public IQueryable<Restaurant> GetRestaurants()
  6:         {
  7:             return this.ObjectContext.Restaurants
  8:                 .Where (r=>r.Region != "NC")
  9:                 .OrderBy(r=>r.ID);
 10:         }
 11:

Ligne 1 : Cet attribut marque le DomainService comme étant accessible via http. Sans lui le service ne peut être appelé que du processus. Ceci est utile dans le scénario ASP.NET Webforms / Dynamic Data.

Ligne 2 : Cette classe est dérivée de LinqToEntitiesDomainService. C'est une classe utilitaire qui fournit quelques helpers pour travailler avec EF. Le vrai travail est effectué par la classe de base DomainService, celle-ci étant la classe à partir de laquelle vous dérivez pour POCO et d'autres scénarios personnalisés.

Ligne 5 : Remarquez que nous renvoyons un IQueryable de notre type DAL Restaurant. IQueryable est l'interface sur laquelle est construite LINQ. Cela offre des fonctionnalités de requêtage supplémentaires au client depuis la couche de données, et ce en prenant en compte votre logique métier personnalisée : possibilité de trier, filtrer, paginer, etc. Cela signifie qu'aucune donnée supplémentaire n'est aspirée dans la couche intermédiaire et le client, mais vous n'avez pas à tordre votre logique métier pour faire face à cela.

Lignes 8-9 : Nous avons une logique métier qui élimine tout Restaurant en Caroline du Nord et met les résultats dans un ordre prédéfini. Vous pouvez, bien sûr, imaginer une logique métier plus intéressante.

Ceci conclut la deuxième partie de cette série. Dans la troisième partie nous verrons comment consommer les données dans le client Silverlight.