WCF DataContract

Question

Si je ne conserve pas le contrat de service, le proxy et le service dans un assemblage séparé, les contrats de service et les proxies résident dans l'assemblage du client, et le service réside dans l'assemblage du service.

Si je ne conserve pas le contrat de données dans un assemblage séparé, où doit-il résider, côté client ou côté service?

Les contrats de données peuvent-ils résider dans les deux assemblages?

Answer 1

Dans un scénario typique, orienté service, vous avez DataContract dans votre bibliothèque de services côté serveur. Toute personne qui vous appellera ajoutera une connexion proxy client à votre service et dupliquera donc votre DataContract.

Donc, dans le "normal" Dans ce cas, vous avez votre " maître " DataContract côté serveur et une classe distincte dans chacun des mandataires clients accédant à votre service. Ces copies clientes sont "identiques sur le fil", par ex. ils se sérialisent dans le même format de message - ce qui est vraiment tout ce qu'il y a entre votre client et votre serveur - un message sérialisé étant envoyé dans les deux sens.

En tant que développeur de services, vous devez absolument disposer de votre DataContract côté serveur. Mais la même chose s’applique aussi aux contrats de service - ceux-ci doivent également être côté serveur - sinon vous ne pourrez pas publier votre interface de service dans le monde entier pour une utilisation par toute personne susceptible de se connecter à votre service.

Je suggère au moins deux projets suivants pour chaque serveur:

• une bibliothèque de classe contenant les contrats de service (interfaces IService), les contrats de données et éventuellement les contrats d'erreur
• une bibliothèque de classe ou un EXE auto-hébergé (application console) contenant l'implémentation réelle du service (les classes implémentant les interfaces de service)

Marc

Answer 2

La réponse est: cela dépend.

Il est généralement préférable de les séparer, mais il peut arriver que les garder ensemble soit une option tout aussi intéressante.

Lorsque vous les séparez, vous pouvez référencer et utiliser votre contrat de données sans faire glisser votre contrat d'exploitation avec lui, ce qui vous donne plus de flexibilité dans la structure de votre application.

Vous pouvez également mettre à jour vos contrats indépendamment.

Mais tout dépend de votre application réelle.

Answer 3

Je recommanderais vivement de disposer d'un assemblage séparé contenant vos interfaces et contrats, qui fait référence à la fois au côté client et au côté serveur.