Juste style personnel, je suppose, mais je déteste avoir 2 fichiers pour mes services WCF. J'ai tendance à copier/coller l'interface dans le fichier .cs pour ne traiter qu'un seul fichier.Y a-t-il une raison de conserver l'interface WCF dans un fichier séparé?
Des dangers en faisant cela?
Pas de dangers en soi - mais il est parfois très utile d'avoir un assemblage séparé avec vos contrats de service, d'opération et de données (uniquement les contrats, les interfaces, essentiellement) - lorsque vous devez partager ceux entre les serveur et le côté client.
Il ne sert à rien de partager le code d'implémentation de service complet (la classe de service réelle, qui implémente l'interface de service) avec le client. Plus: si vous avez vos interfaces dans un fichier séparé (et éventuellement un assemblage), il est plus facile d'écrire des tests unitaires, surtout si vous voulez simuler un service. Obtient un peu brouillon si vous mélangez l'interface et la classe dans un seul fichier. Je considère donc comme une bonne pratique utile et utile de disposer de fichiers séparés pour les interfaces et les implémentations (en fait: toujours une classe par fichier uniquement) et de placer tous les contrats de service et de données (et les contrats de défaut) dans un fichier séparé. Assemblée.
En fait, j'aime aller au-delà de deux fichiers, et avoir deux projets distincts. Un projet contient la définition de l'interface. La valeur principale est pour les tests d'intégration. J'aime faire un troisième projet avec un client WCF. Ce client accède à l'interface dans l'ensemble "partagé".
Rappelez-vous le mantra of Testivus: "Lorsque vous écrivez le code (de production), pensez au test: lors de l'écriture du test, pensez au code."
En accord, +1 pour vous, juste un petit ajout: un fichier Class One. ne pensez-vous pas qu'il s'applique ici aussi d'une certaine façon? –
Merci! Cela a beaucoup de sens et cela semble propre. J'aime ça! – Scottie