Ajout de méthodes de DataContract objets pour WCF

Sont DataContracts dans WCF rien de plus que des Otd? J'ai été dans la lecture de la WCF et juste eu un couple de pensées. Ce serait bien si certains DataContract objets pourrait avoir des méthodes sur eux, de sorte que le client pourrait faire des choses de base avec eux avant ou après l'envoi ou de la récupération de retour au service.

Pour moi, cela ne semble pas possible ou logique. J'ai peut-être tort, j'apprends de nouvelles choses tous les jours. La prochaine meilleure chose à être de traiter DataContracts que Otd et de fournir des bibliothèques pour les clients qui permettrait de créer des objets réels à partir de l'Otd. Objets qui contiennent des méthodes.

Toute orientation serait vraiment apprécié.

Je sais, exactement ce que vous attendez de votre client à faire sur le DataContract? Je pense que vous pouvez gérer que l'initialisation de l'objet type de logique à l'intérieur du constructeur de cette datacontract.

OriginalL'auteur uriDium | 2010-09-17

  1. 9

    Ne sais pas si j'ai bien compris votre réponse, donc corrigez-moi si je me trompe.

    Vous pouvez créer une bibliothèque de classe avec votre DataContracts classes et de partager la bibliothèque entre le client et le serveur. De cette façon, la classe marquée [DataContract] aura méthodes (comportement) et [DataMember] champs/propriétés (de l'etat).

    Quand vous passerez de tels objets entre le client et le serveur via WCF état a persisté, mais depuis la bibliothèque de la classe est partagée, vous aurez des méthodes sur les deux côtés.

    Je suis un idiot. J'ai complètement manqué à l'évidence. Je vais tester pour voir si cela fonctionne.
    Si votre client et le service sont à la fois .Net vous pouvez ensuite générer le proxy client à l'aide de svcutil avec l'option /r pour faire référence à des assemblages existants. Puis les classes pour vous DataContracts peut être partagé.
    Cela peut être fait avec Visual Studio outil de génération aussi?
    Je crois que vous pouvez le faire avec le "Réutiliser les types dans tous les assemblys référencés", bien que je ne peux pas confirmer pour le moment.
    Oui, vous assurer que vous avez déjà ajouté une référence dans le client de l'assemblée contenant du serveur DataContract (POCO de transfert de données de composants), puis sélectionnez le Reuse types in referenced assemblies option dans le Advanced peu en bas à gauche de la WCF Service de Référence de l'assistant.

    OriginalL'auteur Kirill Muzykov

  2. 4

    Otd qui sont décorées comme DataContract classes sont objets réels. Ils peuvent avoir des méthodes en eux, mais les méthodes ne font pas partie du processus de sérialisation.

    Les principaux temps, cela va vous causer des problèmes, c'est quand:

    • vous êtes en s'appuyant sur le proxy généré version de la DataContract objets (comme lorsque vous avez un client Silverlight appel à un service WCF, ou vous appelez un service tiers que vous n'avez pas accès au code ou de ses bibliothèques). Le proxy généré versions n'auront pas les méthodes dans les, juste la DataMember propriétés. Le moyen de le contourner, c'est d'utiliser des objets à partir d'une bibliothèque partagée (comme déjà mentionné par @Insomniaque).

    • vos propriétés dans le DataContract objets sont plus que juste un simple get/set opération, c'est à dire que vous pourriez avoir inclus une certaine logique à faire d'autres opérations lorsque la valeur d'une propriété est définie. Dans ce cas, même le proxy généré version n'aura pas cette logique inclus. Les moyens de contourner cela est de disposer de la bibliothèque partagée, ou avoir une classe partielle sur le côté client qui s'étend le proxy généré classe.

    la classe partielle de la solution j'avais aussi pensé. Pour la plupart, je vais être en mesure de fournir la bibliothèque partagée. Pour d'autres plus sécurisé des trucs où je vais utiliser un webservice je vais faire pour garder mes objets simples.
    un point sur les propriétés qui ont une certaine logique dans DataContract. La propriété getter est appelé sur la sérialisation et de définition est appelée sur la désérialisation à la fin des services. Ainsi, même si le proxy ne fonctionne pas la logique, il sera exécuté lorsque l'objet atteint le service.

    OriginalL'auteur slugster

  3. 0

    Le partage de vos classes entre le client et le serveur de projets est le chemin à parcourir. N'oubliez pas de vérifier dans votre service de référence qu'il essaie de réutiliser les types dans les assemblys référencés. De cette façon, le service de référence ne sera pas générer des classes proxy pour les objets partagés.

    OriginalL'auteur Johann Blais

  4. 0

    WCF, à sa base, est un basé sur le message système: votre client proxy intercepte l'appel d'une méthode, achève la méthode et tous ses paramètres dans un message avec numéro de série, et l'envoyer à travers le réseau pour le service pour être traitées.

    Alors oui, au bout du compte, tous qui va de du serveur vers le client dans WCF est une message avec numéro de série - généralement au format XML. Vous ne pouvez pas sérialiser comportement ou de méthodes avec cette approche.

    OriginalL'auteur marc_s