Nous avons une classe abstraite qui est la base d'un certain nombre de demandes différentes que nous envoyons sur un service de WCF. C'est un pira douineux laids que chaque fois que nous ajoutons une nouvelle demande, nous devons nous rappeler d'ajouter l'attribut Y a-t-il un moyen de dire au [connu> [connexe> à cette classe de base.
DatacontractSerializer pour traiter toutes les dérivations de ce type d'abstrait sous forme de connu de connais ?
4 Réponses :
J'ai eu le même problème dans un service WCF et j'ai fait le piratage "moins odieux" suivant pour travailler autour de la limitation du type connu. Je présente juste pour l'intention de montrer des options alternatives, à vous de décider si c'est mieux ou non.
Au démarrage du service, chargez via la réflexion des types que vous souhaitez exposer. Par exemple. Si toutes vos entités exposées à la WCF dérivent d'une base abstraite commune (ou plus), chargez tous les types de l'assemblage, ils sont supposés être situés. Cache ces types statiquement pour des raisons de performance.
Créez une méthode statique qui renvoie lesdits types de mise en cache, avec la signature suivante:
Marquez l'interface WCF avec l'attribut suivant
Cela devrait vous donner l'exposition automatique de tous types qui sont ou Public Static IEnumerable [ServiceknownType ("Getknowtypes", typeof (staticclassthatcachestypes)]
Merci pour cela. Il ne s'échappe pas vraiment s'il existe plusieurs types de base pour différents types de contrats (devra avoir une aide statique pour chaque base), mais elle prend l'élément humain. :)
@Joe: Pas nécessairement. Si vous avez plusieurs classes de base, rien qui vous empêche de charger tous leurs types dérivés en une fois à l'étape 1. Gélonner des connaissances doit renvoyer une liste de types. Les limitations réelles sont que vous devez connaître toutes vos classes de base (et adapter le chargeur de type lorsque vous en ajoutez une nouvelle) et vous devez savoir où ils se trouvent.
Accepter cela comme une solution de contournement décente. Il serait toujours agréable d'avoir quelque chose d'un peu plus intelligent au niveau de la langue / du compilateur ...
Une autre option en plus de celle donnée par Dan C. consiste à basculer vers le netdatacontractSerializer - Il ne nécessite pas de déclarations de type connues, car elle est étroitement couplée à la mise en œuvre exacte du contrat, vous devez donc partager l'assemblage qui contient les types entre le client et le serveur - et vous perdrez certainement l'interopérabilité dans ce scénario. Il y a quelques postes de faire cela (j'ai vu
Oui, j'espérais éviter cette dépendance. Merci pour la suggestion cependant.
Ce est un exemple de réalisation de cela avec IL Tissage en utilisant Fody / mono.cecil .
Fondamentalement, il s'agit d'un FODY extension qui injecte connuTypeATtributes pendant la durée de construction en utilisant le tissage IL.
Pendant le pipeline de construction, l'extension localise toutes les classes de base marquées de l'attribut connaître (une partie de l'extension) et ajoutera le weattTribute sur toutes les classes qui dérivent (non
nécessairement directement) de l'une des classes de base ci-dessus (avec le savoir-saveurAppsattribute).
Ce est un autre miroir pour le post et ici Vous pouvez trouver le repo GitHub pour l'extension. < / p>
Ne postez pas de réponses uniquement sur le lien; Si le lien disparaît, il s'agit d'un poste inutile.
@Joe j'ai ajouté une brève explication avec plus de miroirs pour le lien. Je ne suis pas sûr que ce sera une bonne idée d'expliquer l'ensemble du blog dans une réponse Stackoverflow.