Discussion :

[rodbeck]

Bonjour,

J'ai développé une application d'administration de mes plateformes.

Chacune de mes plateformes a une instance de mon application installée et peut donc afficher ses propres données (applications installées, clients données infra etc).
J'ai en outre une instance qui s'abonne aux webservices exposés par les autres instances afin d’agréger toutes les données et actions à un seul endroit.

J'ai utilisé les technos MVC3, EF4, Azure Cache Preview, WCF, Azure Service Bus.

Souhaitant augmenter la lisibilité et la maintenabilité de mon application je souhaite modifier son architecture afin de repartir sur un pattern de type Repository, Service.

J'ai suivi les conseils d'un autre site afin d'intégrer mon cache.

Par contre je ne sais pas très bien où insérer mes appels de Webservice dans cette architecture.

A l'heure actuelle, j'ai un seul WebService qui expose toutes les méthodes, peut être pourrais-je passer à un modèle où j'expose un webservice par type d'entité.

Pouvez-vous me conseiller svp ?

Merci.

[Immobilis]

Salut

Par contre je ne sais pas très bien où insérer mes appels de Webservice dans cette architecture.

Je ne suis pas certain de bien comprendre. Peut-être as-tu un schéma? Sinon, les web services sont appelés par les applications clientes. Un client peut être de n'importe quel type Winform, Webform, Mobile...

A l'heure actuelle, j'ai un seul WebService qui expose toutes les méthodes, peut être pourrais-je passer à un modèle où j'expose un webservice par type d'entité.

Ca va être difficile de faire autrement. Un web service ne peut pas avoir deux méthodes avec le même nom. Il ne s'agit pas de la signature. Tu ne peux pas avoir Update(Client client) et Update(Voiture voiture) sur le même web service. Cela génère cette erreur:

System.InvalidOperationException: Impossible d'avoir deux opérations dans le même contrat qui portent le même nom

A+

[rodbeck]

SalutJe ne suis pas certain de bien comprendre. Peut-être as-tu un schéma? Sinon, les web services sont appelés par les applications clientes. Un client peut être de n'importe quel type Winform, Webform, Mobile...

Tout à fait, seulement là mon application est à la fois serveur de webservice et cliente : elle peut s'abonner à d'autres instances de l'application installées sur d'autres plateformes.
En fait je voulais avoir le minimum de code à réécrire possible.

Ca va être difficile de faire autrement. Un web service ne peut pas avoir deux méthodes avec le même nom. Il ne s'agit pas de la signature. Tu ne peux pas avoir Update(Client client) et Update(Voiture voiture) sur le même web service. Cela génère cette erreur:A+

Oui, c'est vrai, ce que je voulais dire, c'est soit je crée un seul WCF avec :

UpdateVoiture(Voiture voiture)
UpdateClient(Client client)

Soit je fais un WCF par type d'objet, je ne sais pas s'il y a des best practices sur ce point.

Merci !

[Invité]

Soit je fais un WCF par type d'objet, je ne sais pas s'il y a des best practices sur ce point.

La best practice voudrait qu'il existe un contrat de service (une classe ou interface décorée de l'attribut ServiceContract) exposant des opérations consommant ou produisant tes entités qui doivent être considérées comme des contrats de données (classes décorées de l'attribut DataContract).

[Immobilis]

Tout à fait, seulement là mon application est à la fois serveur de webservice et cliente : elle peut s'abonner à d'autres instances de l'application installées sur d'autres plateformes.

Pour quels usages? Reporting, maintenance des données? Dans tous les cas il faut se concentrer sur les responsabilités des "modules" de ton application. Moins ton application a de responsabilités plus elle sera facile à maintenir.

Agréger les données de plusieurs instance sur une seule signifie qu'une est maître et les autres esclaves. Tu créés une singularité. Pourquoi ne pas passer par une nouvelle application pour gérer ce besoin? Si il s'agit de reporting SQL Reporting Services est là pour ça.

Si il s'agit de mise à jour, positionner les appels dans le Repository ne me choquerait pas. C'est là que se trouvent les données qu'elle soient derrière un WS ou une base SQL

Oui, c'est vrai, ce que je voulais dire, c'est soit je crée un seul WCF avec :

UpdateVoiture(Voiture voiture)
UpdateClient(Client client)

Soit je fais un WCF par type d'objet, je ne sais pas s'il y a des best practices sur ce point.

Je suis pas fan de la première écriture. Du coup il faudrait plusieurs WS. Pas fan non plus si il y a beaucoup d'entités. Tu seras obligé de créer autant de références que d'entités. A moins d'automatiser le procédé, cela risque d'être un peu lourd.

Fondamentalement, je m’interroge sur la pertinence de ce choix. Une application ne devrait pas avoir besoin de se connecter à ses web service pour mettre à jour ses données. Les WS sont là pour permettre à des systèmes distribués et hétérogènes de communiquer entre eux. Pour les opérations de mise à jour il vaut mieux référencer les dll plutôt que les WS. Tu pourras encore utiliser des Interfaces et tu profiteras des signatures. Pour rappel, une requête http sera toujours plus lente qu'un appel à la dll.

La best practice voudrait qu'il existe un contrat de service (une classe ou interface décorée de l'attribut ServiceContract) exposant des opérations consommant ou produisant tes entités qui doivent être considérées comme des contrats de données (classes décorées de l'attribut DataContract).

Ok et ensuite? Difficile de faire autrement pour créer un service WCF. Sous-entends-tu qu'il devrait faire un WS part entité? Si je ne me trompe, sa question porte sur l'emplacement des appels aux WS dans son architecture.

A+

[rodbeck]

Pour quels usages? Reporting, maintenance des données? Dans tous les cas il faut se concentrer sur les responsabilités des "modules" de ton application. Moins ton application a de responsabilités plus elle sera facile à maintenir.

Pour des usages d'administration : j'ai plusieurs plateformes d'hébergement qui ne communiquent pas à priori entre elles.
Chaque instance de mon appli est installée sur sa propre plateforme et sert ses données via des pages web ou des webservices, chaque application peut en outre s'abonner aux autres.
On peut ainsi se connecter à chaque instance indépendamment pour voir les données d'une plateforme en particulier, ou bien sur l'application abonnée qui agrège les données issues des différents webservice (les données sont conservées en cache, elles ne sont pas dupliquée dans une base de données)

Agréger les données de plusieurs instance sur une seule signifie qu'une est maître et les autres esclaves. Tu créés une singularité. Pourquoi ne pas passer par une nouvelle application pour gérer ce besoin? Si il s'agit de reporting SQL Reporting Services est là pour ça.

C'est là toute la beauté de la chose : il n'y a aucune application maître a priori : chacune des instance peut s'abonner à un ou plusieurs webservices pour afficher les données des autres.
Ces données peuvent être du reporting, mais également des listes "plates" liste d'applications installées par exemple.

Si il s'agit de mise à jour, positionner les appels dans le Repository ne me choquerait pas. C'est là que se trouvent les données qu'elle soient derrière un WS ou une base SQLJe suis pas fan de la première écriture. Du coup il faudrait plusieurs WS. Pas fan non plus si il y a beaucoup d'entités. Tu seras obligé de créer autant de références que d'entités. A moins d'automatiser le procédé, cela risque d'être un peu lourd.

C'est sur ça que je suis parti.

Fondamentalement, je m’interroge sur la pertinence de ce choix. Une application ne devrait pas avoir besoin de se connecter à ses web service pour mettre à jour ses données. Les WS sont là pour permettre à des systèmes distribués et hétérogènes de communiquer entre eux. Pour les opérations de mise à jour il vaut mieux référencer les dll plutôt que les WS. Tu pourras encore utiliser des Interfaces et tu profiteras des signatures. Pour rappel, une requête http sera toujours plus lente qu'un appel à la dll.
Ok et ensuite? Difficile de faire autrement pour créer un service WCF. Sous-entends-tu qu'il devrait faire un WS part entité? Si je ne me trompe, sa question porte sur l'emplacement des appels aux WS dans son architecture.

A+

Le choix du webservice est évident, puisque je dois faire communiquer plusieurs applications installées sur des plateformes (dans des pays) différents.

Merci beaucoup pour vos réponses en tous les cas !

[Immobilis]

Le choix du webservice est évident, puisque je dois faire communiquer plusieurs applications installées sur des plateformes (dans des pays) différents.

Dans ce cas c'est effectivement ce qu'il faut utiliser.

Bonne continuation.