Qu'est-ce que les services WCF RIA ?

Question

Je déteste le site de MSDN pour les services WCF RIA. Il ne dit pas ce que c'est, il dit seulement ce qu'il fait. Il dit ce qu'il peut réaliser mais ne dit pas pourquoi j'en ai besoin.

Par exemple :

"Un problème courant lors du développement d'une solution RIA n-tier est de coordonner logique d'application entre le niveau intermédiaire intermédiaire et le niveau de présentation".

Eh bien, cela ne signifie pas grand-chose pour moi.

"RIA Services résout ce problème en fournissant des composants de cadre, des outils, et des services qui mettent la logique de l'application logique d'application sur le serveur à la disposition du client RIA sans que vous ayez à dupliquer manuellement cette logique de programmation. Vous pouvez créer un client RIA qui connaît les règles de gestion et savoir que le client est automatiquement mis à jour avec la dernière logique de niveau intermédiaire à chaque fois que la solution est recompilée".

Est-ce qu'il télécharge les DLL depuis le serveur ? S'agit-il d'une métadonnée décrivant les règles pour les données ?

Alors, qu'est-ce que c'est ? S'agit-il simplement d'un module complémentaire de VS 2010 pour RAD ? Ou est-ce une technologie au-dessus de WCF ou en dessous, ou quoi ? Où vit-elle ? Avec les données, avec le serveur, quoi ?

J'apprécierais que vous puissiez me résumer cela, s'il vous plaît.

Answer 1

Les services RIA sont une technologie côté serveur qui génère automatiquement des objets côté client (Silverlight) qui se chargent pour vous de la communication avec le serveur et fournissent une validation côté client.

L'objet principal à l'intérieur d'un service RIA est une DomainService généralement un LinqToEntitiesDomainService qui est connecté à un modèle LinqToEntities.

Ce qu'il faut retenir des services RIA, c'est qu'il s'agit principalement d'une astuce de construction sophistiquée. Lorsque vous créez un service de domaine et compilez votre solution, une représentation côté client de votre service de domaine est générée. Cette représentation côté client possède la même interface. Supposons que vous créez un service de domaine côté serveur CustomerService avec une méthode IQueryable<Customer> GetCustomersByCountry . Lorsque vous construisez votre solution, une classe est générée dans votre projet Silverlight appelée CustomerContext qui a une méthode GetCustomersByCountryQuery . Vous pouvez maintenant utiliser cette méthode sur le client comme si vous l'appeliez sur le serveur.

Les mises à jour, les insertions et les suppressions suivent un schéma différent. Lorsque vous créez un service de domaine, vous pouvez indiquer si vous souhaitez activer l'édition. Les méthodes correspondantes de mise à jour/insertion/suppression sont alors générées dans le service de domaine côté serveur. Cependant, la partie côté client ne dispose pas de ces méthodes. Ce que vous avez sur votre CustomerContext est une méthode appelée SubmitChanges . Alors comment ça marche :

• Pour les mises à jour, vous mettez simplement à jour les propriétés des clients existants (que vous avez récupérées par l'intermédiaire de l'application GetCustomersByCountryQuery ).
• Pour les insertions, vous utilisez CustomerContext.Customers.Add(new Customer(...) {...}) .
• Pour les suppressions, vous utilisez CustomerContext.Customers.Remove(someCustomer) .

Lorsque vous avez terminé l'édition, vous appelez CustomerContext.SubmitChanges() .

En ce qui concerne la validation, vous pouvez décorer vos objets côté serveur avec des attributs de validation à partir de l'élément System.ComponentModel.DataAnnotations espace de noms. Là encore, lorsque vous construisez votre projet, le code de validation est maintenant automatiquement généré pour les objets côté client correspondants.

J'espère que cette explication vous aidera un peu plus.