none
Décorer un datacontract avec une classe partielle coté client (ou autre technique pour agrémenter le contract) ? RRS feed

  • Question

  • Bonjour à tous,

     

    Je suis pas mal embetté car j'utilise un WebService WCF qui me transmet des DataContracts coté client et comme vous le savez, si votre contract possède des fonctions ou méthodes, vous ne pouvez pas les appeler coté client de façon simple mais uniquement par appel au webservice).

    J'aurais aimé agrémenter mes datacontracts avec un peu de logique, enfin bref, des trucs tout simples, methodes, fonctions quoi.

    Je me suis dit, pourquoi pas créer une classe partielle coté client qui viendrait se greffer au datacontract lors de la reception de celui ci, mais je ne savais pas que les classes partielles étaient regroupées à la compilation... dommage.

     

    J'aurais souhaité savoir si vous avec une quelconque idée sur comment créer une sorte de décorateur / wrapper simple qui reprenne toutes mes property de mes contracts et si possible automatiquement pour que je puisse ensuite ajouter des methodes et fonctions à celui ci ?

     

    Merci d'avance

    @bientot

    mercredi 24 mars 2010 15:33

Réponses

  • Bonjour,

    Tout d'abord : dans les architectures SOA, si vous souhaitez transférer de la logique (code métier), il faut revoir absolument et d'urgnece votre architecture !

    Normalement, si vous avez du .NET des 2 côtés (client et serveur), je vous conseille de créer un assembly contenant tous vos objets (DataContract) qui seront utilisable (référencé) par le client et le serveur. Vous gagnez en temps et en code.

    Cordialement


    Gilles TOURREAU - MVP C# - Architecte .NET/Consultant/Formateur
    mardi 30 mars 2010 21:42
    Modérateur

Toutes les réponses

  • Bonjour,

    Tout d'abord : dans les architectures SOA, si vous souhaitez transférer de la logique (code métier), il faut revoir absolument et d'urgnece votre architecture !

    Normalement, si vous avez du .NET des 2 côtés (client et serveur), je vous conseille de créer un assembly contenant tous vos objets (DataContract) qui seront utilisable (référencé) par le client et le serveur. Vous gagnez en temps et en code.

    Cordialement


    Gilles TOURREAU - MVP C# - Architecte .NET/Consultant/Formateur
    mardi 30 mars 2010 21:42
    Modérateur
  • Bonjour,

     

    Merci pour la réponse. Alors, effectivement, nous avons du .Net des deux cotés, et nous avions pensé à la même chose, à savoir une assembly commune avec les DTO. Sauf que Silverlight, bah c'est silverlight... On ne peut pas créer une bibliothèque de classes standard et l'utiliser dans Silverlight et vice versa... D'où la problématique.

    Ici l'ajout de logique n'est pas réellement un Ajout à proprement parler, mais plus une agrémentation fonctionnelle en rapport à l'applicatif coté client. Cela permet d'avoir le code proprement cadré au niveau des datacontracts. J'aurais vraiment aimé pouvoir utiliser l'assembly des datacontracts directement dans silverlight...

    mercredi 31 mars 2010 08:15
  • Bonjour tout le monde,

    Pour ce qui est de l'assembly partagé et de Silverlight, j'ai constaté qu'il deviens courant de faire un assembly silverlight et un assembly "normal". L'assembly dit "normal" contient les interfaces. L'assembly Silverlight ne contenant que des raccourcis vers les fichiers contenus dans le premier assembly. Comme cela on n'a pas besoinde faire des doublons dans notre code et on profite des avantages dont à parlé Gilles.


    Jérémy Jeanson MCP http://blogs.codes-sources.com/JeremyJeanson/ (French or English Spoken)
    lundi 12 avril 2010 07:11
    Modérateur
  • Bonjour,

     

    Avez vous déjà essayé de mélanger des projets Silverlight avec des projets dits classiques ? Perso j'ai tenté mais à chaque fois que j'ai voulu référencer un projet classique dans un projet silverlight ou vice versa, ca n'a jamais fonctionné...

    Si vous avez une méthode je suis preneur

    Merci

    @+

    lundi 12 avril 2010 07:42
  • Bonjour insomniak49,

    C'est justement ce dont je parlais :

    2 projet (qui sont sencés servir de réfrence chacun à leur plateforme respective)

    - une librairie "classique"

    - une librairie "silver'light"

    On créé ce classes, interface etc.. dans l'une. Dans l'autre on créé des liens vers les fichier (commande : ajouter fichier, puis ajouter un lien vers au lieu de faire ajouter).

    Et comme celà on a deux librairies avec le même code. Et chacune peut être utilisée dans son contexte à condition de ne pas utiliser de dépendance non compatibles (idéal donc pour de interfaces).


    Jérémy Jeanson MCP http://blogs.codes-sources.com/JeremyJeanson/ (French or English Spoken)
    lundi 12 avril 2010 12:19
    Modérateur
  • Bonjour,

     

    Merci pour cette prompte réponse par contre je ne trouve pas le "ajouter un lien vers". Je suis sous VS2008 et en VB.net. Serait-ce propre à VS2010 ?

     

    Merci d'avance

    @bientot

    lundi 12 avril 2010 12:39
  • Bonjour,

    J'ai sorti le titre de tête. Dans ma version (US) quand je fais ajouter nu fichier existant, mon bouton "Add" donc certainement ajouter en FR a deux fonctions :

    Add : par défaut

    Add as Link... : quand on click sur la petite flèche sur le bouton en bas à droite.

    Voila ;)


    Jérémy Jeanson MCP http://blogs.codes-sources.com/JeremyJeanson/ (French or English Spoken)
    lundi 12 avril 2010 13:23
    Modérateur
  • Ah ouaaaaaaiiiis !!!! vache il était bien planqué le bougre !!!

    Mille mercis !

     

    @ bientot ;)

    lundi 12 avril 2010 14:32
  • Bonjour,

     

    Je viens de faire un test ce matin et il y a un gros problème en fait...

    J'ai deux projets : proj 1 et proj 2

    Proj1 se situe coté client (présentation) , proj2 est un projet coté serveur (avec webservices et accès aux données, code métier...)

    Le but de ma manoeuvre initiale est de pouvoir centraliser le code métier coté serveur et de pouvoir le réutiliser coté client sans avoir à le réécrire. Donc l'histoire d'ajouter en tant que lien me paraissait plus que nickel mais en testant, il s'avere que ce n'est pas bon.

    En fait j'aimerai partager entre proj1 et proj2 des classes partielles. En effet, ces classes partielles me permettraient d'agrémenter mes datacontract par du code de logique qui n'est malheureusement pas transmis lors de l'envoi reception de ces contracts.

    La méthode est donc très simple : j'ai une classe partielle qui décore mon contract coté serveur (proj2). Dans proj1 (coté client) j'ajoute cette classe partielle en tant que lien. Mais là ca ne passe pas du tout car il y a un probleme de namespace. Je dois avouer que je ne maitrise pas vraiment la notion de namespace mais toujours est-il que si dans mon source, j'ai un namespace particulier, je n'ai plus accès aux éléments des autres classes partielles du meme objet et si je vire le namespace de la classe, coté client j'ai beaucoup d'erreurs (comme quoi il y a ambiguité ...)

    Quel genre d'approche pourrais-je avoir à ce niveau svp ?

     

    Merci d'avance

    mardi 13 avril 2010 09:02
  • Bonjour Insomniak49,

    Arg, logique + contrat!!!! Cela ne fonctionne pas comme ça, il faut revoir les bases de WCF. Quand Gilles proposait le partage d'assembly, c'étati pour les contrats. Ceci dans la logique du BAC, un peu comme on le faisait avec le Remoting. Il ne faut pas tout mélanger.

    Pour ce qui est des namespace. Il y a là aussi un petit soucis, on doit avoir un namspece, sans c'est impossible. Il est logique que les deux classes aient le même namespace (en suposant qu'on parle de C#), car celui-ci est écrit dans les fichiers des interfaces. Et donc il est possible que des assembly partagent le même namespace. Même ci ce n'est pas forcement évidant à assimiler quand on relit son code.

    Dans ton cas, des classes partielles, il faut faire attention. Je pense même qu'il y a une petite confusion sur l'utilisation des classes partielles.

     


    Jérémy Jeanson MCP http://blogs.codes-sources.com/JeremyJeanson/ (French or English Spoken)
    mardi 13 avril 2010 09:32
    Modérateur