Récupérer un type d'une classe dans un WCF

Version imprimable

Bonjour à tous,
J'ai un petit soucis concernant mon WCF.
Voici mon schéma pour que vous voyiez à quoi cela ressemble :
http://img202.imageshack.us/img202/8...stitre1rro.png

Ma classe User permet en fait de représenter un tuple de ma base de données.
J'ai donc décidé que c'était (et j'ai pas trop le choix) ma BLL qui devait faire ce mapping.
Il transforme donc mon tuple en un User.

Mon WCF, lui, contient le fichier DLL de la BLL, il y accède et récupère un User via un méthode getUser();.

Ensuite j'ai un client qui détient un proxy de ce WCF.
Via ce Proxy je décide de récupérer un User.
Et là, surprise, ma classe User n'est pas connue, donc mon client ne peut pas faire de requête de ce type :

Code:

MaReferenceWCF.User unUser = monProxy.getUser();

(monProxy étant le proxy de MaReferenceWCF)

Voici à quoi ressemble ma classe :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [DataContract] public class User { String _log; public User(String PLog) { Login = PLog; } [DataMember] public String Login { get { return _log; } set { _log = value; } } }
Quelqu'un a-t-il une idée pour que cette classe soit accessible par le client?

EDIT:
Dois-je rajouter un EndPoint dans mon App.config de mon service ? mon Wcf utilise une interface, qui est une interface de test pour mon premier laboratoire. Cette interface est définie de la même manière que ma classe user à la différence qu'elle est définie dans le Endpoint :
Code:

1 2 3 <endpoint address="" binding="basicHttpBinding" contract="WcfService1.IMyWcfService"/>

29/12/2010, 17h49
Nathanael Marchand

Il ne faut pas oublier de faire un update du "Service Reference".
Il n'y a pas de raisons pour que ca ne marche pas. Ca doit juste être un problème de namespace (regarde dans le "Object Browser" de visual studio pour voir les classes proxy générées)
29/12/2010, 18h04
roxytbl
Petit up pour le EDIT de mon post précédent.

De plus, ne dois-je pas créer une interface pour User du style :
Code:

1 2 3 [ServiceContract] public interface IUser {}
Et ma classe User implémenterait cette interface (public class User : IUser)...
(c'est une idée proposée sur le chat)

Une fois cette interface réalisée, créer un Endpoint sur ce ServiceContract ?

En ce qui concerne l'explorateur d'objets je l'ai déjà parcouru et ne retrouve pas cette classe User...
Bizarre..
29/12/2010, 18h13
Nathanael Marchand

Comme l'indique l'attribut, tu créerais un ServiceContract et non pas un contrat de données.
Non non ce que tu as fait dans le premier post me parait bon.
On peut avoir ton interface de service?

Mon interface de mon service concerne un autre laboratoire, cette interface est bel et bien exposée au client, voici le code de ma classe qui détient le service et la classe ProcessInfo, qui est une classe dont je me servais pour mon premier Labo :

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
31
32
33
34
35
36
37
38
    #region Service
    [ServiceContract]
    public interface IMyWcfService
    {
        [OperationContract]
        DateTime GetDate();
 
        [OperationContract]
        String GetString(String chaine);
 
        [OperationContract]
        ProcessInfo GetProcessInfo(String NomProcess);
 
        [OperationContract]
        List<ProcessInfo> GetRunningProcesses();
    }
    #endregion
 
    [DataContract]
    public class ProcessInfo
    {
        DateTime _heure;
        String _nom;
 
        [DataMember]
        public String nom
        {
            get { return _nom; }
            set { _nom = value; }
        }
 
        [DataMember]
        public DateTime heure
        {
            get { return _heure; }
            set { _heure = value; }
        }
    }

Mon WCF implémente bien ce service et la classe est bel et bien exposée.

30/12/2010, 10h39
roxytbl
Bonjour !
Donv voilà, une petite nouvelle c'est que j'arrive à exposer le User mais c'est du bidouillage et j'aime vraiment pas ça.
En gros, j'ai mon interface IMonWcf qui contient des méthodes que MonWcf implémente. Dans cette interface si je fais une méthode du style :
Code:

1 2 [OperationContract] User getUnUser();
et que je l'implémente dans MonWcf de la manière suivante :

Code:

User getUnUser(){ return new User(); }

Alors là il veut bien m'exposer le User.
Pourquoi suis-je obligé d'avoir une méthode avec un User dans son interface pour qu'il l'expose ?
J'ai bien un ServiceContract et j'y ai associé un endpoint dans mon app.config, le voici :
Code:

1 2 3 <endpoint address="" binding="basicHttpBinding" contract="WcfService1.IMyWcfService"/>
Afin d'exposer mon User, ne dois-je pas créer un second ServiceContract ? Mais si c'est le cas, je ne sais pas quoi mettre dedans car j'ai juste besoin de connaître le type User afin que le client puisse faire

Code:

MaReferenceWeb.User unUser = monProxy.getUnUser();

Merci
30/12/2010, 10h45
Nathanael Marchand
Citation:
Envoyé par roxytbl

Bonjour !
Donv voilà, une petite nouvelle c'est que j'arrive à exposer le User mais c'est du bidouillage et j'aime vraiment pas ça.
En gros, j'ai mon interface IMonWcf qui contient des méthodes que MonWcf implémente. Dans cette interface si je fais une méthode du style :

Code:

1 2 [OperationContract] User getUnUser();

et que je l'implémente dans MonWcf de la manière suivante :

Code:

User getUnUser(){ return new User(); }

Alors là il veut bien m'exposer le User.
Pourquoi suis-je obligé d'avoir une méthode avec un User dans son interface pour qu'il l'expose ?
J'ai bien un ServiceContract et j'y ai associé un endpoint dans mon app.config, le voici :

Code:

1 2 3 <endpoint address="" binding="basicHttpBinding" contract="WcfService1.IMyWcfService"/>

Afin d'exposer mon User, ne dois-je pas créer un second ServiceContract ? Mais si c'est le cas, je ne sais pas quoi mettre dedans car j'ai juste besoin de connaître le type User afin que le client puisse faire

Code:

MaReferenceWeb.User unUser = monProxy.getUnUser();

Merci
Si dans ton interface il n'y a aucune méthode qui n'utilise le type User (en paramètre ou valeur retour) alors effectivement ca ne marchera pas!
(Sauf à utiliser le ServiceKnownType).

Cela dit, quel est l'utilité d'exposer un type si il n'est pas utilisé par les méthodes du webservice? Le ServiceKnownType est utile pour exposer des types dérivés lorsque c'est le type de base abstrait qui est utilisé.
30/12/2010, 10h56
roxytbl

Oui, j'ai remarqué que si aucune méthode n'utilise cette classe alors elle ne sera pas exposée :-)
En fait mes méthodes ne sont pas encore exposées non plus à vrai dire, j'ai vu que le User ne voulait pas venir alors je n'ai pas regardé pour les méthodes retournant un User.
Donc là il me faudrait plus un conseil.
Si tu regardes mon schéma plus haut tu peux voir la couche BLL qui est utilisée par mon WCF; c'est donc les méthodes de la BLL que mon WCF va utiliser. J'ai actuellement un ServiceContract sur le service que mon WCF implémente mais il ne concerne pas la BLL. Comment ferais-tu pour que mon WCF expose les méthodes qu'il utilise de ma BLL ?

EDIT:
Devrais-je dire à MonWcf d'implémenter l'interface IBLL que ma classe BLL implémente déjà ? Ca serait faire 2 fois le même travail non ?
30/12/2010, 11h07
Nathanael Marchand

Citation:

Envoyé par roxytbl

Oui, j'ai remarqué que si aucune méthode n'utilise cette classe alors elle ne sera pas exposée :-)
En fait mes méthodes ne sont pas encore exposées non plus à vrai dire, j'ai vu que le User ne voulait pas venir alors je n'ai pas regardé pour les méthodes retournant un User.
Donc là il me faudrait plus un conseil.
Si tu regardes mon schéma plus haut tu peux voir la couche BLL qui est utilisée par mon WCF; c'est donc les méthodes de la BLL que mon WCF va utiliser. J'ai actuellement un ServiceContract sur le service que mon WCF implémente mais il ne concerne pas la BLL. Comment ferais-tu pour que mon WCF expose les méthodes qu'il utilise de ma BLL ?

EDIT:
Devrais-je dire à MonWcf d'implémenter l'interface IBLL que ma classe BLL implémente déjà ? Ca serait faire 2 fois le même travail non ?

En théorie, un service WCF n'est qu'une passerelle d'accès à distance à la BLL. C'est pourquoi il devrait implémenter ton IBLL.
En pratique, je ne conseille pas car il se peut que tu ne veuilles pas tout exposer.
La propreté et le découplage ont en effet un cout (en faisant parfois deux fois le travail) mais le retour sur investissement est très interessant.
30/12/2010, 11h16
roxytbl

Ok, donc, pour résumer le tout :
J'ai une classe DAL qui est instanciée par ma BLL, cette BLL implémente des méthodes définies dans l'interface IBLL et est instanciée par mon WCF qui lui même implémente les méthodes de l'interface IBLL.

Ma IBLL servirait donc 2 fois mais pour la bonne cause alors, on pourrait mettre des OperationContract sur les méthodes que l'on désire exposer, et ne rien mettre si l'on désire que ça reste entre le WCF et la BLL et que ça porte pas plus haut, c'est ça ? (cf. Image mise à jour dans mon premier post)

Sinon, un peu hors du contexte mais, est-ce normal que je doive instancier une BLL et une DAL pour le WCF ? Ne dois-je pas plutôt avoir toutes les méthodes en statique ? je veux dire par là que pour moi ça a aucun intérêt d'avoir des instances de ces classes, si j'instancie c'est uniquement pour avoir accès aux méthodes pour que ces classes communiquent... Dis moi ce que tu en penses si tu veux bien :)

Merci de répondre si vite et d'éclaircir ce côté sombre de mon esprit ! :ccool:
30/12/2010, 11h44
Nathanael Marchand

Citation:

Envoyé par roxytbl

Ok, donc, pour résumer le tout :
J'ai une classe DAL qui est instanciée par ma BLL, cette BLL implémente des méthodes définies dans l'interface IBLL et est instanciée par mon WCF qui lui même implémente les méthodes de l'interface IBLL.

Ma IBLL servirait donc 2 fois mais pour la bonne cause alors, on pourrait mettre des OperationContract sur les méthodes que l'on désire exposer, et ne rien mettre si l'on désire que ça reste entre le WCF et la BLL et que ça porte pas plus haut, c'est ça ? (cf. Image mise à jour dans mon premier post)

Sinon, un peu hors du contexte mais, est-ce normal que je doive instancier une BLL et une DAL pour le WCF ? Ne dois-je pas plutôt avoir toutes les méthodes en statique ? je veux dire par là que pour moi ça a aucun intérêt d'avoir des instances de ces classes, si j'instancie c'est uniquement pour avoir accès aux méthodes pour que ces classes communiquent... Dis moi ce que tu en penses si tu veux bien :)

Merci de répondre si vite et d'éclaircir ce côté sombre de mon esprit ! :ccool:

Comme je l'ai dit plus haut, personellement je préfèrerait que WCF n'implémente pas IBLL mais plutôt une autre interface qui ressemble à IBLL qui à le gout de IBLL mais qui n'est pas IBLL.

Ensuite pour l'histoire des instances et du statique, la encore c'est une histoire de préferences et de besoins. D'une manière générale je dirais que tout mettre en statique c'est bof. Tu n'as pas le contrôle sur la durée de vie des objets et ca peut te poser des problèmes que je vais expliquer juste après. Après tu peux créer une instance pour chaque requête. Chaque client à ainsi sa petite instance de bll, de dal et son petit copain ne viendra pas lui piquer. C'est la solution propre la plus simple à mettre en place mais elle peut être gourmande en mémoire (poids d'une instance x nombre de clients). Enfin, il reste la meilleure (à mon gout) qu'est de créer des singletons partagés par tout le monde. Mais là, attention! Avec les singletons ou le "tout static" il y'a le problème de concurrence d'accès. Deux clients qui interrogent la dal au même moment partagent les même valeurs des variables d'instance. Inimaginable donc de maintenir la connexion à la base en variable d'instance! Il faut donc que les instances soient stateless (sans état)

Le must du must est pour moi une solution avec singleton géré par un gestionnaire d'injection de dépendances comme Unity. La DAL est injecté de manière transparente à la BLL, la BLL est injectée à la couche de service, etc. De plus tu peux régler aisément dans les fichiers de config si tu veux du singleton ou multi-instance ou singleton par thread etc. Mais ca ferait l'objet d'un autre post :D

Eh bien je pense que je passerai à cette histoire de singleton partagés et gérés par un gestionnaire d'injection plus tard alors, j'aurai de quoi épater le prof :P.
Je vais rester avec mes instances d'objets pour le moment, être sûr que ça tourne bien, et si j'ai le temps j'irai faire mes recherche là dessus :-)!

Sinon, tu me dis qu'il faut que mon interface ait la gueule de ma IBBL sans l'être réellement. Donc si on regarde sur le schéma de mon premier post il faudrait en fait glisser une interface entre IBLL et MonWcf alors ? Et dans cette interface je sélectionnerai ce que j'ai envie d'exposer ou non, c'est ça l'idée ?
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 public interface IBLL { User getUser(); void UneMethode(); } [ServiceContract] public interface IMyWcfServiceExamen : IBLL { [OperationContract] User getUser(); void UneMethode(); } public class MonWcf : InterfaceWCF, IMyWcfServiceExamen { #region Méthodes de InterfaceWCF ... #endregion public User getuser() { return new User(); } public UneMethode() { //N'importequoi } }

30/12/2010, 12h12
Nathanael Marchand
Citation:
Envoyé par roxytbl

Eh bien je pense que je passerai à cette histoire de singleton partagés et gérés par un gestionnaire d'injection plus tard alors, j'aurai de quoi épater le prof :P.
Je vais rester avec mes instances d'objets pour le moment, être sûr que ça tourne bien, et si j'ai le temps j'irai faire mes recherche là dessus :-)!

Sinon, tu me dis qu'il faut que mon interface ait la gueule de ma IBBL sans l'être réellement. Donc si on regarde sur le schéma de mon premier post il faudrait en fait glisser une interface entre IBLL et MonWcf alors ? Et dans cette interface je sélectionnerai ce que j'ai envie d'exposer ou non, c'est ça l'idée ?

Code:

1 2 3 4 5 6 7 8 9 10 public interface IBLL { User getUser(); void UneMethode(); } [ServiceContract] public interface IMyWcfServiceExamen : IBLL { [OperationContract] User getUser(); void UneMethode(); }
Ca ne marcherait pas! Dire que IMyWcfServiceExamen implémente IBLL signifie qu'il reprend toutes les méthodes de IBLL et c'est justement ce qu'on veut eviter. C'est ce lien qu'il faudrait casser.
30/12/2010, 12h20
roxytbl

Ah ok, complétement casser le lien alors. Si je me dois de casser le lien c'est par convention ? C'est parce que le client n'est pas censé connaître les méthodes de la BLL directement qu'il faut créer une seconde interface ?
Car à part devoir réécrire une "partie" de mes méthodes de ma BLL dans ce service je ne vois pas ce que cela apporte.
Mais si c'est par convention et que c'est comme ça qu'un développeur se doit de voir les choses eh bien je ferai comme ça :)

EDIT:
Voir mise à jour de l'image du premier post
30/12/2010, 13h15
Nathanael Marchand

Citation:

Envoyé par roxytbl

Ah ok, complétement casser le lien alors. Si je me dois de casser le lien c'est par convention ? C'est parce que le client n'est pas censé connaître les méthodes de la BLL directement qu'il faut créer une seconde interface ?
Car à part devoir réécrire une "partie" de mes méthodes de ma BLL dans ce service je ne vois pas ce que cela apporte.
Mais si c'est par convention et que c'est comme ça qu'un développeur se doit de voir les choses eh bien je ferai comme ça :)

Bof c'est surtout à l'usage que tu verras que c'est moins contraignant.

Il y'a plusieurs raisons à cela.
Premier exemple: Les signatures diffèrent légèrement entre service
Toutes tes méthodes de ta BLL marchent par utilisateur, dans chaque méthode t'as un paramètre user. Bien sur avec WCF, tu n'exposes pas le paramètre user qui est determiné côté serveur selon l'identification sur le serveur. Mais la méthode pour déterminer l'user n'est pas la même qu'en ASP.Net par exemple. La bll n'a pas spécialement à prendre en compte cette considération qui doit plutot être dans l'implémentation du service.

Second exemple: Toutes méthodes ne sont pas forcément exposables.
Soit par choix, soit par raisons de sécurités, soit parceque l'objet à renvoyer n'est pas sérialisable, soit etc.
30/12/2010, 16h40
roxytbl

C'est bien gentil de ta part de m'avoir apporté ton aide!
Encore un grand merci je vais enfin pouvoir avancer un peu! (Oui, un peu, car j'ai encore une question mais qui en sera un autre sujet et en ASP, mais quand j'aurai terminé la partie WPF d'abord :))
Je prends en compte ce que tu m'as donné comme informations à propos des singleton :).

Une très bonne année 2011 à toi!