Question d'architecture WCF.

Bonjour à tous.

J'ai suivi beaucoup de tutos sur la création d'un service web WCF et j'ai quelques questions.

Dans beaucoup de tutos l'exemple montre une seule classe avec une seule interface. sur la théorie je suis d'accord mais mon WCF a moi comprendra une 20aine de classes dont certaines implementeront des interfaces d'autres pas du tout.

Je souhaitais donc savoir si cela posais probleme et surtout SI toute classe qui possède une méthode dite "metier" doit implementer l'interface contenant la signature de(s) méthode(s).

Merci d'avance.

Cédric DANIEL.

Citation:

---

Envoyé par cedric.daniel

Bonjour à tous.

J'ai suivi beaucoup de tutos sur la création d'un service web WCF et j'ai quelques questions.

Dans beaucoup de tutos l'exemple montre une seule classe avec une seule interface. sur la théorie je suis d'accord mais mon WCF a moi comprendra une 20aine de classes dont certaines implementeront des interfaces d'autres pas du tout.

---

Ben, oui, un service en général à une finalité autre que d'exposer des interfaces pour tester WCF :D

Citation:

---

Je souhaitais donc savoir si cela posais probleme et surtout SI toute classe qui possède une méthode dite "metier" doit implementer l'interface contenant la signature de(s) méthode(s).

---

Bien sur que non : tes seules classes spécifiques sont celles qui implémentent les interfaces. Les autres doivent simplement être sérialisables (je ne parle que de celles qui constituent des objets "métiers" que tu vas exposer via tes interfaces, les autres "internes" à ton service ne rentrent pas en ligne de compte ici), et porter l'attribut DataMember sur les champs qui doivent être pris en compte lors de la sérialisation par WCF.

Quelques précautions supplementaires, notamment la taille des buffers des méthodes "WCF" retournant des listes et la profondeur du graphe de sérialization.

Voir aussi l'attribut "KnownType" qui te sera très certainement indispensable.

En général, chez moi, un ensemble appli client + serveur va comprendre au minimum, les assemblies suivantes :

Assemblies communes :

- une assembly avec les interfaces de communications WCF
- une assembly avec les objets métiers (je n'aime pas utiliser les proxys autogénérés si j'ai la main sur le client).

Coté serveur :

- une assembly "server" qui va comprendre les classes d'implémentation des interfaces de communications et les classes métiers.
- une assembly serviceHosting qui est le .exe qui instanciera les classes d'implémentation des interfaces, et hébergera le serviceProcessInstaller et tutti quanti.
- une assembly consoleHosting pour faciliter le développement, qui a le même role que l'assembly serviceHosting , mais qui tourne en console.

cote client :

- une assembly "communication-layer" qui appellera les méthodes des interfaces de communication et encapsulera le traitement d'erreur; elle peut aussi contenir les régles métiers "clients".
- une assembly client (IHM en général, mais pas forcément) qui attaquera la précédente et pourra êre aussi l'exe client.

Bien sur, c'est un minimum (dans la pratique il y en a beaucoup plus - par exemple, en général, il y a toujours une DAL, qui est attaqué par l'assembly serveur, etc ....)

N'hésite pas si tu as des questions plus précises !

D'accord je vois a peu pres ou je met les pied.

En fait, a partir de mon application SILVERLIGHT, seuls les methodes qui sont definies dans un contrat seront visibles, apres faudra que mes methodes retournent des objets serialisées pour travailler avec.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

[DataContract] public classe Personne : IPersonne { private String nom; private String prenom;   [DataMember] public String Prenom { get {} set {} }   [...]     public void enregister() {   } }   [ServiceContract] interface IPersonne { [operationContract] void enregister(); }

---

En gros voila comment travaille mon projet.

Est ce que dans les textes ceci est correcte ou je suis a coté de la plaque ?

Là tu as mélangé classe métier (quoique je préférerai plutôt parler ici de DTO) et service.

Tu dois partir d'une interface qui décrit les fonctionnalités de ton service (comme tu l'a fais). Par exemple le fait d'enregistrer une personne : tu déclare une méthode Enregister qui prend en paramètre un objet Personne.
Appelle cette interface IPersonneService par exemple.

Code:

---

1 2 3 4 5 6 7

[ServiceContract] interface IPersonneService { [operationContract] void Enregister(Personne personne); }

---

Après tu crée une classe (PersonneService par exemple) qui implémente cette interface. Cette classe est différente de ta classe Personne. Ce n'est pas ta classe Personne qui est le service.

Absolument rien à ajouter à ce qu'a écrit The Badger Man.

J'allais faire une réponse du même tonneau.

Merci, je vois mes erreurs. je vais pouvoir corriger tout ca.

Donc maintenant que j'ai ma classe PersonneService, je peux tres bien faire une classe ProduitService qui sauvegardera mes produits.

Hum petite question aussi. Est ce qu'il faut que je declare mes classe Personne, produit, comme serializable et que je fasse des methodes de serialization d'objet ou WCF a deja tout prévu ?

Merci pour vos lumières. Je commence vraiment a aimer WCF.

Cédric DANIEL.

Citation:

---

Envoyé par cedric.daniel

Hum petite question aussi. Est ce qu'il faut que je declare mes classe Personne, produit, comme serializable

---

Je t'ai répondu déjà au dessus sur ce point.

Tu déclare les objets qui transit par WCF avec l'attribut Serializable et l'attribut DataContract.

Citation:

---

et que je fasse des methodes de serialization d'objet ou WCF a deja tout prévu ?

---

Tu n'as pas à faire de méthodes de sérialization, il sérialisera tous les membres qui ont l'attribut DataMember.

En revanche, (c'est valable pour presque tous les Serializers d'ailleurs) , chaque objet doit avoir un constructeur sans paramètre.

Attention aussi aux membres en readonly, qui ne pourront pas être sérialisés; donc si tu affectes de tels membres dans des constructeurs avec paramètres, vire le déclarateur readonly et met l'attribut DataMember (qui n'a pas de sens sur un membre readonly), sinon ca va merder. (ils se retrouveront avec la valeur précisée dans le constructeur sans paramètres).

Ah oui désolé j'avais mal compris

Je met le post en résolu

Bonne soirée ;) Merci pour tout