Discussion :

[klx234]

Bonjour,

J'ai développé un jeu en XNA qui marche à merveille et je veux le mettre en réseau pour que 2 joueurs s'affrontent (hors ligne ). Donc je débute avec WCF. Ce dernier me demande de créer des interfaces pour mes méthodes(Projet1) dans un nouveau projet(Projet2) dans la même solution.

Le problème est que mes méthodes prennent en paramètres des classes dans Projet1 qui ne sont pas accessibles dans Projet2. Projet2 ne peut pas référencer Projet1 sinon il y aurait dépendance circulaire .

Donc dans Projet2, je ne peux pas faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void Manger(Aliment aliment, Moment moment);

// où Aliment est une classe dans Projet1 et Moment est un type enum prenant par exemple les valeurs "matin", "midi", "soir"

Est-ce que quelqu'un aurait une solution?

[micka132]

Projet2 ne peut pas référencer Projet1 sinon il y aurait dépendance circulaire .

Si tu définis ton interface WCF au niveau de projet 1, ton projet 2 peut très bien le réferrencer afin de fournir une implementation de cette interface. Projet 1 lui ne sera pas lié à 2 via reférence puisqu'il n'y a pas besoin.

Mais je pense que ce n'est pas forcement le plus clair.

Le mieux est sans doute d'avoir un projet qui ne contient que les classe de donnée (datamodel) et éventuellement les interfaces dont tu as besoin avec (ou sinon egalement dans un autre projet, mais ca alourdi)
Projet1 fait donc reference à ProjetDataModel, et projet2 fait lui aussi reference à ProjetDataModel. Il n'y a aucun lien entre projet1 et projet2, si ce n'est leurs réference commune à PorjetDataModel

[Noxen]

Option 1 : tout rassembler en un seul projet ; ce n'est pas ce que je recommanderais, bien au contraire, mais je pense que c'est possible, il doit suffire de référencer les assemblies nécessaires.
Option 2 : extraire dans un projet à part les classes utilisées par l'application et par le projet WCF (c'est le point 2 proposé par micka132).
Option 3 : si le projet WCF contient le contrat du service mais pas son implémentation il n'y a pas besoin d'avoir de classe commune ; classes et méthodes du projet WCF servent à exposer le service mais ne sont pas forcément à utiliser pour le réaliser et ne représentent pas la même chose ; par exemple ta méthode Manger pourrait prendre directement un identifiant d'aliment (par un int, un Guid ou un string), qui permettra de sélectionner l'objet à utiliser dans le service.

Ensuite tu peux revoir un peu l'architecture de ton programme. Je ne connais pas XNA mais je suppose que tu dois pouvoir extraire certains éléments comme les objets de jeu que tu as créé, il s'agit de déterminer les responsabilités de chacun pour savoir qui a besoin de qui, en passant éventuellement par des "contrats".

[ZenZiTone]

Le mieux est sans doute d'avoir un projet qui ne contient que les classe de donnée (datamodel) et éventuellement les interfaces dont tu as besoin avec (ou sinon egalement dans un autre projet, mais ca alourdi)
Projet1 fait donc reference à ProjetDataModel, et projet2 fait lui aussi reference à ProjetDataModel. Il n'y a aucun lien entre projet1 et projet2, si ce n'est leurs réference commune à PorjetDataModel

+1 ! L'interface a pour rôle de jouer le contrat entre ton service et ton client. Il faut donc qu'elle soit dans un projet différent, avec l'ensemble des objets qui sont concernés par ce contrat, afin de permettre aux projets d'avoir un cycle de vie différent de celui du contrat.

[klx234]

Effectivement, j'ai séparé les projets WCFServices, WCFInterfaces, Host, et Client (Client est le projet XNA). Je sais que le concept même du WCF est que le client ne devrait pas avoir accès direct au code d'implémentation des méthodes(WFCServices) d'où la création des interfaces(WCFInterfaces).

Bon, je vais vous expliquer mon projet:

- WCFServices fait référence à WCFInterfaces et contient 5 classes : Classe1, Classe2, Classe3, Classe4 et Classe5. Classe1 a une méthode qui appelle en paramètre Classe1 lui même et Classe2 =>public void Methode1(Classe1 classe1, Classe2 classe2){}

- WCFInterfaces fait référence à System.ServiceModel et contient 4 interfaces : IClasse1, IClass2, IClasse3 et IClasse5. Or dans IClasse1, je ne peux pas écrire
void Methode1(Classe1 classe1,Classe2 classe2) parce que Classe1 et Classe2 sont dans un autre projet. WCFInterfaces ne référencie pas WCFServices sinon cela créerait une dépendance circulaire. Donc, ma solution, a été de transformer les paramètres en attributs. Je sais c'est très très moche mais ça marche .

- Host fait référence à Sytem.ServiceModel, WCFInterfaces et WCFServices.

- Client fait référence à System.ServiceModel, WCFInterfaces.

Bref, j'ai un autre souci maintenant, un problème de connexion : The socket connection was aborted. "This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:59.1160000'."
Besoin d'aide

[ZenZiTone]

- WCFInterfaces fait référence à System.ServiceModel et contient 4 interfaces : IClasse1, IClass2, IClasse3 et IClasse5. Or dans IClasse1, je ne peux pas écrire
void Methode1(Classe1 classe1,Classe2 classe2) parce que Classe1 et Classe2 sont dans un autre projet. WCFInterfaces ne référencie pas WCFServices sinon cela créerait une dépendance circulaire. Donc, ma solution, a été de transformer les paramètres en attributs. Je sais c'est très très moche mais ça marche .

La méthode de contrat ne devrais pas être Methode1(Classe1 classe1,Classe2 classe2) , mais Methode1(IClasse1 classe1,IClasse2 classe2).
Si tes classes Classe1, Classe2, Classe3, Classe4 ne contiennent que des attributs (s'il n'y a pas de méthodes métier) alors tu peux également les mettre dans le contrat.

[klx234]

Merci ZenZiTone cela marche aussi. Donc, c'est résolu .

Il ne me reste que le problème de Socket TimeOut excedeed. Je vais essayer d'utiliser DuplexChannelFactory au lieu de ChanneFactory. Mais ceci ne concerne plus cette discussion.

Merci à tous