Deux services WCF avec différents contrats mais les mêmes objets métier

Question

Par exemple, j'ai deux services hébergés dans IIS.

[ServiceContract] 
public interface IDeviceService 
{ 
    [OperationContract] 
    DeviceCollection GetAllDevices(Customer customer); 

} 

[ServiceContract] 
public interface IUserService 
{ 
    [OperationContract] 
    User Authenticate(string username, string password); 

} 

deux l'objet utilisateur qui est renvoyée par l'opération Authentifier dans le UserService et la DeviceCollection qui est renvoyée par l'opération GetAllDevices dans le DeviceService ont une définition d'objet enfant du Client. Le client est un objet métier dans le même assemblage que les objets Utilisateur et Périphérique.

Mon problème est sur le client - quand je l'appelle le fonctionnement du dispositif

userProxy.GetAllDevices(user.Customer); 

Le compilateur se plaint avec le message suivant:

Argument 1 - Impossible de convertir UserService.Customer à DeviceService.Customer

Je peux me connecter aux deux services très bien, c'est la définition d'objet du client qui est le problème. Je ne veux pas vraiment mettre les Opérations dans le même service qu'elles semblent vivre naturellement dans leurs propres services. Je suppose que ce que je demande est que comment d'autres programmeurs font face à un tel problème?

Cheers, Stuart

Answer 1

Si vous souhaitez partager un contrat de données sur plusieurs services, alors vous devrez compiler le contrat de données en question dans sa propre assemblée et ensuite distribuer cette assemblée au client.

Même si le type apparaît être identique, il est en fait un deux types distincts et c'est pourquoi vous voyez l'erreur que vous voyez. Votre seul autre choix (autre qu'un assemblage séparé et partagé) consiste à combiner les deux services en un seul afin qu'ils puissent partager le contrat de données.

Answer 2

Je pensais que j'essaierais de répondre à ma propre question avec des détails sur la façon dont je viendrais à bout de cette solution. Il était basé sur un article sur un blog article by Dan Meineck.

Est résumé, je pense que mon concept d'avoir plusieurs services pour chacune de mes entités commerciales racine a été mal orienté.

Au lieu de cela j'ai exposé un service unique qui mettait en œuvre plusieurs DataContracts, par exemple

public partial class DeviceService : IDeviceService, IUserService 
{ 
} 

Parce que le service de l'appareil est créé en tant que classe partielle cela m'a permis de séparer les services, eh bien je dis à part, ils sont toujours le même service mais cela m'a permis de les séparer en fichiers séparés et de donner une organisation structurelle au service.

Le dernier morceau de la mise en œuvre a été de déclarer deux points finaux dans la définition du service, par exemple

<service behaviorConfiguration="GPSCloudHost.DeviceServiceBehavior" name="BusinessService.DeviceService"> 
<endpoint address="Device" binding="wsHttpBinding" contract="BusinessService.DataContracts.IDeviceService"></endpoint> 
    <endpoint address="User" binding="wsHttpBinding" contract="BusinessService.DataContracts.IUserService"></endpoint> 
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> 

Je ne suis pas connu dans WCF enought dire si cela est « bonne » solution ou pas, mais ça fonctionne un régal pour mes exigences. Si quelqu'un d'autre a une meilleure solution, j'aimerais l'entendre!

À votre santé

Answer 3

C'est un problème sémantique. Si vous voulez définir un UserService.Client et DeviceService.Customer étant sémantiquement égaux, vous devez physiquement redéfinir ce contrat de données dans un ensemble distinct. Alternativement, si vous voulez définir UserService.Customer et DeviceService.Customer comme étant sémantiquement différents, conservez-les en tant que types distincts et écrivez une fonction utilitaire pour traduire de l'un à l'autre.

Answer 4

Une option serait d'utiliser AutoMapper sur le client pour convertir de façon transparente d'un type à un autre. Comme ils ont les mêmes propriétés, les mappings seraient simples.