2009-06-08 4 views
2

J'ai 2 objets à créer identiques sauf qu'ils se réfèrent à mes services dev et test WCF. Fondamentalement, ce sont l'objet pour le service lui-même, et l'objet pour un DTO créé par le contrat de données WCF.oo question: appliquer la même logique à 2 objets similaires

Dans mon client de test, je crée soit les 2 objets liés au service dev WCF, soit les 2 objets liés au service WCF de test. J'applique ensuite une logique identique à la fois pour tester mon contrat de service, etc.

Quelle est la meilleure façon de structurer ceci en utilisant les principes OO, de préférence sans avoir à écrire la logique deux fois?

Pour référence, voici les objets que je crée. Le premier jeu provient de "ASRServiceClient". Le second jeu provient de "ASRTestServiceClient".

ASRService.ASRServiceClient svc = new ASRService.ASRServiceClient(); 
ASRService.ASRItem tr1 = new ASRService.ASRItem(); 
+2

S'il vous plaît écrivez ce que votre question est dans le titre si vous voulez que quelqu'un le regarde .. – Macke

Répondre

4

Pourquoi avez-vous besoin de modifier le code dans votre client basé sur le service que vous vous connectez à? Ne seriez-vous pas capable d'avoir 2 fichiers .config différents? Un qui contient la connexion pour le service de dev et un qui contient la connexion pour le service de test? Il suffit de changer les fichiers .config basés sur le mode test/dev.

Bien entendu, le contrat pour votre service serait une interface et les deux versions de développement et de test du service utilisent cette même interface de contrat, mais cela ne semble pas être ce que vous demandiez.

Edit:

Extrait d'une interface ServiceContract pour votre service si vous ne l'avez pas déjà fait. Vos services de développement et de test doivent tous deux implémenter l'interface. Quelque chose comme ceci:

[ServiceContract(Namespace="http://stackoverflow.com/questions/965977")] 
public interface IASRService 
{ 
    [OperationContract] 
    ASRItem GetASRItem(); 
} 

Votre fichier app.config (ou web.config) pour votre client doit contenir quelque chose comme celui-ci où {namespace} est l'emplacement d'espace de nom de votre interface. Si vous vouliez les conserver dans un seul fichier .config, cela fonctionnera.

<system.serviceModel> 
    <client> 
    <endpoint name="ASRService" address="http://yourserver.com/ASRService" 
       contract="{namespace}.IASRService" binding="basicHttpBinding"/> 
    <endpoint name="ASRServiceTest" address="http://localhost/ASRService" 
       contract="{namespace}.IASRService" binding="basicHttpBinding"/> 
    </client> 
</system.serviceModel> 

Le code de votre client qui utilise les services devrait ressembler à ceci. Indiquez le nom de la configuration dans le constructeur ChannelFactory.

ChannelFactory<IASRService> cf = new ChannelFactory<IASRService>("ASRService"); 
IASRService proxy = cf.CreateChannel(); 

ASRItem DevServiceItem = proxy.GetASRItem; 

OU

ChannelFactory<IASRService> cfTest = new ChannelFactory<IASRService>("ASRServiceTest"); 
IASRService proxyTest = cfTest.CreateChannel(); 

ASRItem TestServiceItem = proxyTest.GetASRItem; 

Étant donné que le type de proxy est soit toujours IASRService, le code que vous avez qui manipule les objets que doit savoir sur ce type d'interface. Il ne devrait pas se soucier quelle version du service a généré l'objet.

Aussi, je recommanderais le livre Learning WCF par Michele Leroux Bustamante. De bons exemples sur la façon de faire tout ça!

+0

Cela semble être une bonne idée, est-il un moyen simple de modifier le fichier de configuration par programme? – alchemical

1

Utilisez une interface.

0

Je voudrais utiliser une interface et avoir un paramètre dans votre fichier de configuration qui détermine au moment de l'exécution quelle classe concrète créer.

0

Vous pouvez utiliser un Template method, en encapsulant les données spécifiques à l'environnement pour vos services dans les sous-classes. Cependant, il ne s'agit peut-être pas d'un motif. Il peut être préférable d'avoir des fichiers de configuration spécifiques à l'environnement.

Questions connexes