Bonjour,

J'ai une question qui me trote à l'esprit ces temps-ci, peut-être quelqu'un a-t-il déjà fait face à ce problème. Je suis en train de développer un programme, principalement pensé par Windows Phone 7, mais qui aura peut-être dans le futur un penchant WPF et ASP.NET. Ce faisant, le programme sera pensé en Modèle MVC dès le départ pour accommoder une nouvelle interface très facilement.

Cependant, je me demande si je devrais compiler ces classes dans une dll externe, au risque de devoir forcer une mise-à-jour des applications lourdes lorsqu'un changement est nécessaire dans la structure des syntaxes ou autre, ou si je crée un service WCF.

La seconde solution me semble la meilleure, car plus flexible, et si il y a un bug à corriger, il pourra l'être sans que l'utilisateur n'ait à faire une mise-à-jour, ce qui sur Windows Phone 7 pourrait se traduire en plus de téléchargement dans le forfait. Cependant, ma vraie question est celle-ci : Je ferais un projet de type Application WCF qui génère un projet ASP.NET. Pour héberger ce service, est-ce qu'il faut que quelques fonctionnalités additionnelles soient activées, ou le Framework 3.5 ou 4.0 (selon le cas) sera suffisant en lui-même dès qu'il est couplé à IIS ? Dois-je rechercher pour un nom spécifique de fonctionnalité ? Et finalement, pourriez-vous me proposer des hébergeurs qui acceptent ce genre de service (même si payant, mais raisonnable svp ).

Je vous remercie beaucoup de me répondre !
gretro

Up ?

Citation : gretro

Cependant, je me demande si je devrais compiler ces classes dans une dll externe, au risque de devoir forcer une mise-à-jour des applications lourdes lorsqu'un changement est nécessaire dans la structure des syntaxes ou autre, ou si je crée un service WCF.

Beaucoup de développeur utilisent l'outil svcutils.exe pour générer un proxy de service dans l'application cliente. Si mise à jour il y a, ils doivent rafraichir ce proxy avant de recompiler la solution et la redéployer. Personnellement, je trouve cette technique un peu trop redondante (j'ai horreur des codes dupliqués...et svcutils.exe recrée toutes les interfaces de service que tu as déjà faites + tous les pocos que tu aurais pu faire + une classe de connexion au service avec les méthodes adaptées). Si je devais te conseiller là dessus, je mettrais tout dans une DLL à part, pour éviter d'avoir du code en double dans le projet et que dans les deux cas, on est obligé de recompiler .

Citation : gretro

Je ferais un projet de type Application WCF qui génère un projet ASP.NET. Pour héberger ce service, est-ce qu'il faut que quelques fonctionnalités additionnelles soient activées, ou le Framework 3.5 ou 4.0 (selon le cas) sera suffisant en lui-même dès qu'il est couplé à IIS ? Dois-je rechercher pour un nom spécifique de fonctionnalité ? Et finalement, pourriez-vous me proposer des hébergeurs qui acceptent ce genre de service (même si payant, mais raisonnable svp ).

Pas spécialement. Si l'hébergeur choisi supporte les applications ASP.NET, normalement, il supporte les services WCF. Vérifie quand même, ça ne serait pas étonnant que les hébergeur jouent là dessus pour faire payer plus (genre un "Serveur IIS 7 à 12€/mois? C'est ici. Attention : Ce service ne propose que l'hébergement de page aspx. Tout autre contrôle inclus dans votre projet ne sera pas accessible")

Des hébergeurs à te proposer....Pour tout te dire, sur les quelques projets que j'ai pu faire en techno Microsoft, les services étaient tous déployés sur des serveurs dédiés car dans tous les cas, c'était le plus flexible (choix de la base de données, choix de l'install IIS, de la version .NET, etc etc.). Si t'as les moyens de mettre 30€/mois dans un dédié, ce sera p'tet le moins contraignant.

Personnellement j'ai un doute sur le fait que WCF soit une bonne idée dans ton cas.

Si j'ai bien compris, tu veux surtout utiliser WCF pour "factoriser" du code et pouvoir réutiliser la logique qu'il contient via plusieurs clients différents.
Or l'utilisation d'un web service est justifiée dans deux cas:
- s'il existe un système centralisé qui offre un accès unique à des données. Le service web constitue alors l'interface publique de ce système, et permet d'intéragir avec lui et (indirectement) avec sa base de données.
- si des tâches de calcul très lourdes doivent être exécutées, et qu'il est plus rapide d'envoyer une requête à un super-calculateur et d'attendre le résultat que de l'exécuter "sur place".

Pour tout le reste, rien n'empêche de créer une DLL avec ton code et à la réutiliser dans tous les clients qui en ont besoin. Les clients seront un peu plus lourds évidemment, mais tu t'épargneras toutes les difficultés liées à la communication client-serveur, en particulier la création de la couche de communication (interface du web service etc) et les temps de réponse à travers le net.

C'est vrai que tu aurais plus de contrôle si toute ta logique métier était concentrée en un point que tu pourrais facilement mettre à jour en cas de bug, mais l'idée que ça permettrait aux utilisateurs d'économiser du forfait me semble un peu bancale. il ne faut pas oublier qu'un service web consomme aussi de la bande passante... Et puis à ce moment-là, pourquoi ne pas faire un site web ?

Pour ce qui concerne les hébergeurs, je n'en connais pas de gratuits. Il faut effectivement s'assurer qu'ils te permettront bien d'exposer un service sur un autre port que le port 80, ce qui n'est pas gagné d'avance.

Les services WCF peuvent transiter par le protocol HTTP, car il s'agit majoritairement de SOAP, non ?

La raison également de cette question réside dans le fait que j'ai envie de pouvoir exporter l'application sur d'autres plateformes / langages. Aujourd'hui, je code en C# sur Windows Phone 7, mais demain, j'aimerais peut-être coder en C# pour Windows avec WPF afin de faire un client lourd de cette application. Et pourquoi pas de l'Objective-C un jour afin de rendre le tout accessible pour les Macs. Le problème, c'est qu'avec une Dll, il faudrait que je reprogramme dans le cas d'un changement de langage ou d'OS. Le service WCF, lui, utilise du SOAP, ce qui est au final du XML. Ce XML est finalement très universel et est le format d'échange parfait, non ?

Merci pour vos réponses, je dois encore évaluer les pours et les contres de chaque méthode, et merci pour la mise-en-garde des hébergeurs.

Merci encore de vos réponses,
gretro

Citation : gretro

Les services WCF peuvent transiter par le protocol HTTP, car il s'agit majoritairement de SOAP, non ?

Oui.

Citation : gretro

La raison également de cette question réside dans le fait que j'ai envie de pouvoir exporter l'application sur d'autres plateformes / langages. Aujourd'hui, je code en C# sur Windows Phone 7, mais demain, j'aimerais peut-être coder en C# pour Windows avec WPF afin de faire un client lourd de cette application. Et pourquoi pas de l'Objective-C un jour afin de rendre le tout accessible pour les Macs. Le problème, c'est qu'avec une Dll, il faudrait que je reprogramme dans le cas d'un changement de langage ou d'OS. Le service WCF, lui, utilise du SOAP, ce qui est au final du XML. Ce XML est finalement très universel et est le format d'échange parfait, non ?

Tant que ça reste en techno Microsoft "recoder" la couche métier me semble louche => Cette couche devrait être dans une dll à part. Dès lors, s'il s'agit de la rendre opérationnelle pour plusieurs techno .NET, il suffit de recréer des projets pour la techno ciblée, de faire les ajouts de classes par lien et d'utiliser la compilation conditionnelle pour gérer les différents cas de plateforme (SILVERLIGHT pour une lib Silverlight, WP7 pour Windows Phone 7 je crois...et <rien> pour du WPF). Ainsi, tu as un seul projet "consistant" (qui contient les vrai codes sources) et tous les autres qui contiennent des liens vers ces codes sources => Ils ne sont pas à recoder.

Après, si ça sort de Microsoft, effectivement, le mieux, c'est encore d'utiliser un service.

J'ai l'impression que tu cherches à résoudre un problème de portabilité. Or c'est bien connu, .Net ne brille pas par cet aspect-là. La portabilité est un problème complexe, et à ma connaissance la technologie "la plus portable" à l'heure actuelle c'est... HTML. Ou en tout cas, c'est l'objectif principal d'HTML5. Java se défend pas mal, mais n'est pas pris en charge sur tous les supports Apple (sauf erreur de ma part).

Je ne suis pas un grand défenseur du HTML, bien au contraire. Mais si ta priorité est de faire une application portable, tu devras sans doute envisager d'autres technos - ou en tout cas t'intéresser aux dernières technos portables et compatibles .Net (Mono et cie). Si ce n'est pas ta priorité, il faudra s'attendre à faire des concessions.

Les services Web ne sont pas une réponse au problème de la portabilité. C'était un rêve il y a 15 ans: on s'imaginait qu'on allait pouvoir créer des objets à différents endroits du monde et sur des plateformes différentes et tout ce petit monde allait pouvoir intéragir de manière transparente comme s'il s'agissait d'une seule application. On en est largement revenu.

Citation : Nisnor

il suffit de recréer des projets pour la techno ciblée, de faire les ajouts de classes par lien et d'utiliser la compilation conditionnelle pour gérer les différents cas de plateforme

Une autre solution consiste à bidouiller le fichier .csproj pour créer des configurations supplémentaires: par exemple on garde "Debug" et "Release" pour la compilation .Net 4.0, et on crée des configurations "Silverlight Debug" et "Silverlight Release" pour la compilation Silverlight. C'est un peu technique, mais au moins on n'a qu'un seul projet et il suffit de modifier la configuration active pour cibler tel ou tel environnement

Citation : Orwell

Les services Web ne sont pas une réponse au problème de la portabilité. C'était un rêve il y a 15 ans: on s'imaginait qu'on allait pouvoir créer des objets à différents endroits du monde et sur des plateformes différentes et tout ce petit monde allait pouvoir intéragir de manière transparente comme s'il s'agissait d'une seule application. On en est largement revenu.

Dans ce cas, il y a deux écoles : Celle qui considère ce que tu décris...Et celle qui considère qu'un service peut aussi être utilisé pour centraliser une couche métier. Personnellement, j'suis plus de celle qui dit qu'un service sert à centraliser (Du code...Des données...Des objets?) et que si on veut faire une interface graphique pour tous les OS du monde, on devrait utiliser un service pour éviter de se casser la tête . En logique entreprise, ce serait p'tet même plus rentable => A développer un service, on paye le serveur et 2-3 dev pour développer puis maintenir le service.... C'est mieux que de payer continuellement 10-12 dev, pour le dev initial puis pour la maintenance, dont chaque lot de 2-3 dev sera spécialisé pour une plateforme donnée et dans tous les cas, on doit quand même rajouter les frais liés à l'hébergement des données.

C'est d'ailleurs ce que je planifiais faire. La couche métier et la couche de données seront exécutés dans le service, puis l'interface graphique sera exécuté du côté client selon le bon vieux modèle MVC.

Citation : Nisnor

Tant que ça reste en techno Microsoft "recoder" la couche métier me semble louche => Cette couche devrait être dans une dll à part.

Ne t'inquiète pas, je ne suis pas si "noob" . J'allais soit faire une dll pour faire en sorte que les couches métiers et de données soient les même, puis de retravailler la couche d'interface selon la plateforme utilisée, soit un service WCF qui contienne les couches métier et de données.

Mon idée penche de plus en plus vers la solution du service, voyant également que mon professeur de programmation m'encourage à prendre cette voie. Le pire qui arrive, c'est que je me plante, et que j'apprenne de mes erreurs, non ?

Juste pour clarifier: je ne suis pas en train de dire que les services Web c'est mal. Au contraire, j'en ai moi-même un paquet déjà déployés ou en cours de développement.

Mais je continue à dire qu'il faut une bonne raison pour vouloir en mettre un en place (typiquement centraliser des données et/ou des ressources), et que si le but est simplement de factoriser du code alors autant aller jusqu'au bout et suivre l'approche SaaS (Software as a Service), en ayant uniquement un portail web et plus aucun logiciel client.

J'agrée bien avec toi Orwell. Je crois que les applications web sont la meilleure solution. Cependant, je désire participer à un concours organisé par Microsoft afin de promouvoir leur plateforme Windows Phone 7.

En développant un service WCF, cela me permet également de penser à une solution web pour plus tard.