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

[Proteus91]

En tout cas si tu as besoin d'aide. N'hésite pas.

[cnguyen]

Un grand merci pour vos réponses.

Pour répondre à David :
L'application web est de l'ASP.NET, l'application lourde utilise les technologies .NET (application tactile avec un graphisme fait manuellement en utilisant les librairies Microsoft) et le client riche est Silverlight. Ainsi, ces services seront interrogés principalement par des applications .NET.

Cependant, il n'est pas impossible que plus tard, une application en Delphi ou autres technologies viennent interroger ces services.

Bien entendu, application lourde est devenu synonyme d'application riche mais c'était simplement pour indiquer que l'application lourde sera installé sur chaque poste client contrairement à la riche qui sera accessible via le navigateur.

Sinon, tu dis "WCF RIA Services fournit les mêmes services". En effet, avec WCF RIA Services on peut aussi faire du LINQ Request. La seule chose qui change (globalement) alors est le fait que la communication ne soit pas en REST mais en SOAP?

De plus, il est aussi possible d'utiliser les OData pour communiquer avec d'autres applications (comme tu l'as très bien montré dans l'un de tes posts). Cependant, tu dis :

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.

L'exposition du OData de WCF RIA Services n'est pas la même que celle du Data Services ? Moins de fonctionnalités ? Et qu'est ce qui empêche de faire une communication SOAP entre un service WCF et Delphi par exemple ? Ce que je veux dire c'est qu'avec le SOAP on peut aussi communiquer avec des applications non .NET. Non ?

Ainsi, si j'ai uniquement des applications .NET qui interrogeront mes services, la meilleure solution est donc WCF RIA Services.
Si j'ai d'autres applications non .NET qui sont susceptibles d'interroger mes services, alors il est mieux de se tourner vers WCF Data Services.
Enfin, WCF n'est pas utile dans mon cas (et même pour tous les cas non ?)

Pour ma part, l'idéal serait de pouvoir d'avoir une solution en WCF RIA Services contenant tous mes services. D'avoir trois autres solutions (une en Silverlight, une en client lourd maison en .NET et une en ASP.NET) qui pourrait interroger ces services. En Silverlight, cela me permettrait d'éviter la réécriture de code (validation, métier, etc). En client lourd, d'interroger tout simplement mes services et en client léger aussi (possible d'avoir le même mécanisme de génération qu'en Silverlight mais pour l'ASP.NET ?)

Merci encore à tous!

Je file regarder ce webcast en attendant de vos nouvelles.

[Nathanael Marchand]

Un grand merci pour vos réponses.

Pour répondre à David :
L'application web est de l'ASP.NET, l'application lourde utilise les technologies .NET (application tactile avec un graphisme fait manuellement en utilisant les librairies Microsoft) et le client riche est Silverlight. Ainsi, ces services seront interrogés principalement par des applications .NET.

Cependant, il n'est pas impossible que plus tard, une application en Delphi ou autres technologies viennent interroger ces services.

Bien entendu, application lourde est devenu synonyme d'application riche mais c'était simplement pour indiquer que l'application lourde sera installé sur chaque poste client contrairement à la riche qui sera accessible via le navigateur.

Sinon, tu dis "WCF RIA Services fournit les mêmes services". En effet, avec WCF RIA Services on peut aussi faire du LINQ Request. La seule chose qui change (globalement) alors est le fait que la communication ne soit pas en REST mais en SOAP?

De plus, il est aussi possible d'utiliser les OData pour communiquer avec d'autres applications (comme tu l'as très bien montré dans l'un de tes posts). Cependant, tu dis :

L'exposition du OData de WCF RIA Services n'est pas la même que celle du Data Services ? Moins de fonctionnalités ? Et qu'est ce qui empêche de faire une communication SOAP entre un service WCF et Delphi par exemple ? Ce que je veux dire c'est qu'avec le SOAP on peut aussi communiquer avec des applications non .NET. Non ?

Ainsi, si j'ai uniquement des applications .NET qui interrogeront mes services, la meilleure solution est donc WCF RIA Services.
Si j'ai d'autres applications non .NET qui sont susceptibles d'interroger mes services, alors il est mieux de se tourner vers WCF Data Services.
Enfin, WCF n'est pas utile dans mon cas (et même pour tous les cas non ?)

Pour ma part, l'idéal serait de pouvoir d'avoir une solution en WCF RIA Services contenant tous mes services. D'avoir trois autres solutions (une en Silverlight, une en client lourd maison en .NET et une en ASP.NET) qui pourrait interroger ces services. En Silverlight, cela me permettrait d'éviter la réécriture de code (validation, métier, etc). En client lourd, d'interroger tout simplement mes services et en client léger aussi (possible d'avoir le même mécanisme de génération qu'en Silverlight mais pour l'ASP.NET ?)

Merci encore à tous!

Je file regarder ce webcast en attendant de vos nouvelles.

L'interet d'un procotole comme SOAP c'est d'être multiplateforme(ca marche en java, php,etc)
De plus avec WCF, tu peux décider si t'exposes du SOAP,REST, etc

[davrous]

L'exposition du OData de WCF RIA Services n'est pas la même que celle du Data Services ? Moins de fonctionnalités ? Et qu'est ce qui empêche de faire une communication SOAP entre un service WCF et Delphi par exemple ? Ce que je veux dire c'est qu'avec le SOAP on peut aussi communiquer avec des applications non .NET. Non ?

Ainsi, si j'ai uniquement des applications .NET qui interrogeront mes services, la meilleure solution est donc WCF RIA Services.
Si j'ai d'autres applications non .NET qui sont susceptibles d'interroger mes services, alors il est mieux de se tourner vers WCF Data Services.
Enfin, WCF n'est pas utile dans mon cas (et même pour tous les cas non ?)

Hello,

Non, le support d'OData de RIA Services n'est pas du tout le même que celui de Data Services comme je l'explique dans cet article : http://blogs.msdn.com/b/davrous/arch...point-2-5.aspx

Ensuite, effectivement, le endpoint SOAP de RIA Services est alors le plus adapté pour les autres clients .NET (comme les non-.NET comme JAVA, PHP & co). Cependant, en utilisant le endpoint SOAP de RIA Services, on perd la possibilité d'effectuer du filtrage à la source depuis le client. En effet, en RIA Services depuis le client Silverlight, on peut parametrer la requête pour demander à notre source serveur de n'envoyer qu'un sous-ensemble particuliers des entitées (grâce à LINQ côté client et au IQueryable côté Serveur). On perd cela avec les endpoints SOAP, JSON et bien sûr OData.

Par contre, on retrouve cette possibilité avec le support complet d'OData de WCF Data Services.

Tout ça pour dire qu'il faut bien analyser ce que chacun des framework nous apporte. Il n'y a pas de framework magique qui couvre tout les besoins pour tous les clients avec le maximum de productivité. Par contre, que ce soit WCF RIA services ou WCF Data Services, les 2 reposent sur WCF qui est très générique et sur lequel vous pourrez toujours redescendre si nécessaire.

Bye,

David