Propager Application Service comme service WCF

Question

J'ai la description de mes services d'application en utilisant mes classes de fantaisie (de ServiceDescription classe qui contient la collection de Description ServiceMethod, pour simplifier).

Maintenant, je veux exposer un service d'application en tant qu'un service de WCF (un contrat). La solution actuelle est très boiteuse - J'ai une application console qui génère un fichier * .svc pour chaque service d'application (ServiceDescription). Il existe une méthode (opération) générée pour un ServiceMethod.

Cela fonctionne bien mais je voudrais l'améliorer. Il pourrait être amélioré en utilisant le modèle T4 mais je suis sûr qu'il y a encore mieux dans la WCF. Je voudrais toujours avoir un fichier * .svc pour un service d'application mais je ne veux pas générer de méthodes (pour les méthodes de service d'application correspondantes). Je suis sûr qu'il doit y avoir des interfaces qui permettent de découvrir les opérations dynamiquement, au moment de l'exécution. Peut-être IContractBehavior ...

Merci.

EDIT1: Je ne veux pas utiliser un contrat d'exploitation générique parce que je voudrais avoir la capacité de générer proxy de service avec toutes les opérations.

Je suis sûr que si j'écris manuellement le service et les opérations WCF, alors WCF utilise la réflexion pour découvrir les opérations dans le service. Maintenant, je voudrais personnaliser ce point afin de ne pas utiliser de réflexion, utilisez plutôt mon "code de découverte d'opérations".

Answer 1

Je pense qu'il n'y a rien de mal à la génération de code statique dans ce cas. À mon avis, c'est une meilleure solution que la génération dynamique de contrats. Gardez à l'esprit que votre contrat est la seule preuve que vous avez/fournissez qu'un service héberge un ensemble particulier d'opérations.

Le problème principal que je vois à propos de l'approche dynamique concerne le versionnement et la compatibilité. Si tout est généré de manière dynamique, vous risquez de pousser de manière transparente les modifications importantes dans le système et de créer des problèmes avec les clients existants.

Si vous avez un générateur de code lorsque vous prévoyez d'implémenter des modifications dans les services d'application, il sera plus facile de se rappeler que les modifications que vous apportez aux services peuvent avoir un impact énorme. Mais si vous voulez vraiment gérer les messages de manière dynamique, vous pouvez utiliser un contrat d'opération générique (avec la propriété Action définie sur *) et acheminer manuellement les messages aux services d'application. Gardez à l'esprit que vous perdriez la possibilité de générer à partir du service un proxy contenant une liste d'opérations disponibles.