Je déteste le site 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 accomplir mais ne dit pas pourquoi j'en ai besoin.
Par exemple:
"Un problème courant lors du développement d'une solution RIA à n niveaux est la coordination de la logique d'application entre le niveau intermédiaire et le niveau de présentation".
Eh bien, cela ne signifie pas grand-chose pour moi.
"Les services RIA résolvent ce problème en fournissant des composants, des outils et des services d'infrastructure qui mettent la logique d'application sur le serveur à la disposition du client RIA sans vous obliger à dupliquer manuellement cette logique de programmation. Vous pouvez créer un client RIA qui connaît les règles métier et sachez que le client est automatiquement mis à jour avec la dernière logique de niveau intermédiaire chaque fois que la solution est recompilée. "
Alors, télécharge-t-il les DLL à partir du serveur? S'agit-il d'une métadonnée décrivant les règles des données?
Alors c'est quoi? S'agit-il simplement d'un module complémentaire VS 2010 pour RAD? Ou est-ce une technologie au-dessus de WCF ou en dessous ou quoi? Où est-ce que ça vit? Avec des données, avec un serveur, quoi?
J'apprécie si vous pouvez me résumer cela s'il vous plaît.
Les services RIA sont une technologie côté serveur qui génère automatiquement des objets côté client (Silverlight) qui prennent en charge la communication avec le serveur pour vous et fournissent une validation côté client.
L'objet principal d'un service RIA est un DomainService
, généralement un LinqToEntitiesDomainService
qui est connecté à un modèle LinqToEntities.
La chose clé à retenir dans les services RIA est que c'est principalement 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 a 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 générez 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 modèle différent. Lorsque vous créez un service de domaine, vous pouvez indiquer si vous souhaitez activer la modification. Les méthodes correspondantes de mise à jour/insertion/suppression sont ensuite générées dans le service de domaine côté serveur. Cependant, la partie côté client n'a pas ces méthodes. Ce que vous avez sur votre CustomerContext
est une méthode appelée SubmitChanges
. Donc comment ça fonctionne:
GetCustomersByCountryQuery
).CustomerContext.Customers.Add(new Customer(...) {...})
.CustomerContext.Customers.Remove(someCustomer)
.Une fois l'édition terminée, vous appelez CustomerContext.SubmitChanges()
.
En ce qui concerne la validation, vous pouvez décorer vos objets côté serveur avec des attributs de validation de l'espace de noms System.ComponentModel.DataAnnotations
. Encore une fois, lorsque vous générez votre projet, le code de validation est désormais généré automatiquement pour les objets côté client correspondants.
J'espère que cette explication vous aidera un peu plus loin.
Dernières nouvelles: WCF RIA Services est mort:
http://blogs.msmvps.com/deborahk/who-moved-my-cheese-ria-services/
Si vous souhaitez utiliser les services RIA, ils ont été open source: