Discussion :

[cnguyen]

Bonjour à tous,

Dans le cadre d'un projet orienté métier, j'ai pour but de créer un projet se basant sur la technologie Silverlight.

J'ai comme contrainte l'utilisation d'entités déjà existantes (donc pas d'utilisation d'ORM) et la création de services qui devront être utilisable par une application web, une application lourde, une application riche. A noter que je dois envisager deux solutions, une avec le framework 3.5 et une avec le 4.

Le but principal est d'éviter la redondance de code (code métier, règle métier, etc...).

A la base, je comptais partir sur l'architecture suivante :
Silverlight 4 (en MVVM ?) <-> WCF <-> BLL <-> DAL <-> SQL Server 2008

Cependant, je m'intéresse aussi aux solutions WCF Data Services et WCF RIA Services.

Quel est le choix le plus judicieux entre ces 3 technologies dans mon contexte ? Sont-elles toutes utilisables pour mon problème ? Est-il possible d'avoir ce qu'apporte WCF RIA Services (éviter de dupliquer le code côté client et serveur) via WCF ?

Merci d'avance pour votre aide.

[Nathanael Marchand]

Bonjour à tous,

Dans le cadre d'un projet orienté métier, j'ai pour but de créer un projet se basant sur la technologie Silverlight.

J'ai comme contrainte l'utilisation d'entités déjà existantes (donc pas d'utilisation d'ORM) et la création de services qui devront être utilisable par une application web, une application lourde, une application riche. A noter que je dois envisager deux solutions, une avec le framework 3.5 et une avec le 4.

Le but principal est d'éviter la redondance de code (code métier, règle métier, etc...).

A la base, je comptais partir sur l'architecture suivante :
Silverlight 4 (en MVVM ?) <-> WCF <-> BLL <-> DAL <-> SQL Server 2008

Cependant, je m'intéresse aussi aux solutions WCF Data Services et WCF RIA Services.

Quel est le choix le plus judicieux entre ces 3 technologies dans mon contexte ? Sont-elles toutes utilisables pour mon problème ? Est-il possible d'avoir ce qu'apporte WCF RIA Services (éviter de dupliquer le code côté client et serveur) via WCF ?

Merci d'avance pour votre aide.

Pour moi, je trouve WCF Data Services et WCF Ria Services déportent beaucoup de logique métier côté Client(donc Silverlight) (cependant je reconnais ne pas avoir poussé assez mes tests dessus).

Cependant je pense que les trois peuvent être utilisées.
Pour la dernière question, non tu ne peux pas avoir la duplication via WCF cependant rien ne t'empeche de partager une déclaration de classe entre ton projet Silverlight et ton projet Server

[Proteus91]

Hello,

Je voulais juste te faire part d'un exemple que j'utilise pour un de mes clients. Il a plusieurs applications (Winform, WPF et Silverlight) tous ces projets etaient montés autour de MVC et MVVM. Dans le cadre de l'harmonisation de l'accès aux données. Nous avons cassé l'architecture de ces applications pour monter a la place du Modele un service WCF. Du coup nous n'avions plus qu'une zone a maintenir pour l'accès aux données.

[GuruuMeditation]

L'avantage des WCF RIA c'est que tu va ecrire des règles de validations une fois, et elles vont être générées du côté client automatiquement. Ca evite de devoir écrire 2 fois la même chose pour le client et le serveur. Et c'est plus simple pour la maintenance.

[cnguyen]

Merci pour vos différentes réponses

Pour vous répondre :
@PitMaverick78 : En effet, les WCF RIA/Data Services déportent du code mais c'est, je pense, du code utile qui va éviter de faire un aller-retour serveur.

@Proteus91 : Merci pour ton retour d'expérience. En effet, comme tu le dis, je compte bien utiliser une architecture SOA afin de n'avoir qu'un code commun pour toutes les applications. Cependant, cela n'empêche pas de faire du MVC ou MVVM côté client qui ira interroger les services. Non ? Sinon, ma problématique est plutôt de savoir quelle technologie correspond le mieux à mon scénario.

@EquinoxeDotNet : Merci. Mais comment se positionne Data Services par rapport à cela ?

----
Ainsi, ma question est de savoir quelle technologie utiliser pour mon scénario :
- Est-ce que toutes les technologies se valent ?
- Est-ce qu'il y a une technologie qui est moins pérenne qu'une autre (comme le Linq-To-Sql envers EF) ?
- Est-ce que l'on peut dire que WCF RIA/Data Services sont des sur-couches à WCF et permettent donc, en quelque sorte, de faire tout ce que fait WCF + d'autres améliorations ?
- De plus, le fait d'avoir un client lourd qui va interroger ses services, n'exclut-il pas l'utilisation de WCF RIA Services ?

De ce que j'ai pu lire, j'ai l'impression que WCF RIA Services réunit WCF et WCF Data Services. C'est à dire qu'il centralise la définition des règles de validation des données, il diffuse le modèle de données côté client, il y a un proxy de communication qui utilise Linq pour requêter (ADO.NET DataServices) et il gère la génération automatique des points de terminaison (WCF) lors du déploiement de l'application (au nombre de 3 : WsHttpBinding, BinaryHttpBinding et BasicHttpBinding).

Ai-je tort ?

[Proteus91]

Alors oui effectivement rien ne t'en empêche. Cela dit pour ma part je n'ai pas utilisé RIA, je reste encore pour l'instant très fidèle au bon vieux Composant WCF Maison

[Nathanael Marchand]

Merci pour vos différentes réponses

Pour vous répondre :
@PitMaverick78 : En effet, les WCF RIA/Data Services déportent du code mais c'est, je pense, du code utile qui va éviter de faire un aller-retour serveur.

@Proteus91 : Merci pour ton retour d'expérience. En effet, comme tu le dis, je compte bien utiliser une architecture SOA afin de n'avoir qu'un code commun pour toutes les applications. Cependant, cela n'empêche pas de faire du MVC ou MVVM côté client qui ira interroger les services. Non ? Sinon, ma problématique est plutôt de savoir quelle technologie correspond le mieux à mon scénario.

@EquinoxeDotNet : Merci. Mais comment se positionne Data Services par rapport à cela ?

----
Ainsi, ma question est de savoir quelle technologie utiliser pour mon scénario :
- Est-ce que toutes les technologies se valent ?
- Est-ce qu'il y a une technologie qui est moins pérenne qu'une autre (comme le Linq-To-Sql envers EF) ?
- Est-ce que l'on peut dire que WCF RIA/Data Services sont des sur-couches à WCF et permettent donc, en quelque sorte, de faire tout ce que fait WCF + d'autres améliorations ?
- De plus, le fait d'avoir un client lourd qui va interroger ses services, n'exclut-il pas l'utilisation de WCF RIA Services ?

De ce que j'ai pu lire, j'ai l'impression que WCF RIA Services réunit WCF et WCF Data Services. C'est à dire qu'il centralise la définition des règles de validation des données, il diffuse le modèle de données côté client, il y a un proxy de communication qui utilise Linq pour requêter (ADO.NET DataServices) et il gère la génération automatique des points de terminaison (WCF) lors du déploiement de l'application (au nombre de 3 : WsHttpBinding, BinaryHttpBinding et BasicHttpBinding).

Ai-je tort ?

Alors Linq-To-SQL tu peux oublier en effet, c'est EF mainteant
WCF Data et WCF Ria sont en effet des surcouches qui permettent de partager de l'intelligence.
Un client lourd peut aussi consommer les services de WCF Ria Services (cf les articles de davrous http://blogs.msdn.com/b/davrous/ )

[chrisdot]

Sinon, il y a aussi CSLA, qui me paraît la façon la plus flexible de construire une appli n-tiers. Bon, ça nécessite un temps d'apprentissage...

[cnguyen]

@Proteus91 : En effet, à la base j'ai toujours fait du WCF, je comptais donc me lancer dessus. Mais à la vue des WCF RIA/Data Services, j'ai été freiné dans mon élan lol

J'ai l'impression que les technologies se chevauchent ainsi :
- WCF (base)
- WCF Data Services (sur-couche à WCF pour l'ajout du LINQ Request)
- WCF RIA Services (sur-couche à WCF Data Services dans le sens où il gère la duplication de code mais aussi le LINQ Request)

Ainsi, je vois différents chemins de résolution :
- Avec .NET 3.5 : l'utilisation de WCF en créant un projet pour l'UI, un pour les services, et un autre stockant le business afin qu'il soit partager côté client et côté service.

En effet, avec .NET 3.5, impossible d'utiliser RIA Services (disponible qu'en .NET 4 ?). Pour ce qui est de WCF Data Services, il faudrait opter pour ADO.NET Data Services. Hormis le nom qui a changé de ADO -> WCF, y a t il de grosses évolution ?

- Avec .NET 4.0 : soit WCF, soit RIA Services qui m'a l'air d'être une sur-couche à Data Services.

Qu'en pensez-vous ?

[davrous]

Hello,

Vu la description rapide de ton besoin : "une application web, une application lourde, une application riche", j'aurais plutôt tendance à dire à la louche WCF Data Services.

Cependant, il faudrait que tu précises les technologies de chacune des applications. Web = Silverlight, ASP.NET, PHP, AJAX? Quelle est la différence pour toi entre l'application lourde et l'application riche?

Sinon, attention, WCF RIA Services ne repose pas sur WCF Data Services. RIA Services et Data Services reposent bien sur la stack WCF en fournissant chacun un ensemble de services différent. Mais ils vivent cote à cote.

WCF Data Services fournira les services suivants : Exposition des données sous forme de services REST avec support du CRUD et filtrage à la source

WCF RIA Services fournit les mêmes services avec en plus de l'intelligence pour tenter de masquer la dernière partie de l'architecture n-tiers (client vers le service) et pour aider à la création des écrans Silverlight (règles de validations, contrôles de haut niveau, etc.).

WCF RIA Services vise donc principalement un frontal Silverlight même si effectivement j'ai démontré que l'on peut s'en servir de manière annexe pour d'autres clients comme WPF, Windows Phone 7 ou HTML5.

Mais si ton application lourde ou riche n'est pas du monde .NET, mieux vaut regarder WCF Data Services qui propose une exposition en OData parfaite pour cela.

Pour finir, ce webcast réalisé avec mon collègue Mitsu pourra peut-être t'éclaircir : Session Applications d'entreprise avec .Net 4.0 et Silverlight 4 des Microsoft Days 2010 . Nous y abordons rapidement le positionnement de WCF Data Services vs WCF RIA Services dans une grande partie du Webcast.

Bye,

David Rousset
Microsoft France