oo вопрос: применение той же логики к 2 подобным объектам

Question

У меня есть 2 объекта для создания, которые идентичны, за исключением того, что они ссылаются на мои службы разработки и тестирования WCF. По сути, это объект самого сервиса и объект DTO, созданный контрактом данных WCF.

В моем тестовом клиенте я создаю либо 2 объекта, связанных со службой dev WCF, либо 2 объекта, связанных с тестовой службой WCF. Затем я применяю одинаковую логику для проверки моего контракта на обслуживание и т. Д.

Каков наилучший способ структурировать это, используя принципы ОО, желательно без необходимости писать логику дважды?

Для справки, вот объекты, которые я создаю. Первый набор от "ASRServiceClient". Второй набор происходит от "ASRTestServiceClient".

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

Answer 1

Зачем вам нужно изменить код в вашем клиенте в зависимости от того, к какой услуге вы подключаетесь? Разве вы не могли бы иметь 2 разных файла .config? Тот, который содержит соединение для службы разработки, и тот, который содержит соединение для службы тестирования? Просто отключите файлы .config в режиме тестирования / разработки.

Конечно, контракт для вашего сервиса будет интерфейсом, и обе версии, и dev, и тестовые версии сервиса, будут использовать один и тот же контрактный интерфейс, но это не то, о чем вы просили.

Edit:

Извлеките интерфейс ServiceContract для вашего сервиса, если вы этого еще не сделали. Ваш dev и test services должны реализовывать интерфейс. Примерно так:

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

Ваш файл app.config (или web.config) для вашего клиента должен содержать что-то вроде этого, где {namespace} - это пространство имен вашего интерфейса. Если вы хотите сохранить их обоих в одном файле .config, это сработает.

<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>

Код вашего клиента, который использует службы, будет выглядеть следующим образом. Укажите имя конфигурации в конструкторе ChannelFactory.

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

ASRItem DevServiceItem = proxy.GetASRItem;

OR

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

ASRItem TestServiceItem = proxyTest.GetASRItem;

Поскольку типом любого прокси-сервера всегда является IASRService, ваш код, управляющий объектами, должен знать только об этом типе интерфейса. Не важно, какая версия сервиса генерирует объект.

Также я бы порекомендовал книгу Learning WCF Мишеля Леру Бустаманте. Прекрасные примеры того, как сделать все это!

Answer 2

Использовать интерфейс.

Answer 3

Вы можете использовать Шаблонный метод , инкапсулирующий данные среды для ваших услуг в подклассы. Тем не менее, это не может быть вопросом шаблона. Лучше всего иметь конфигурационные файлы для конкретной среды.

Answer 4

или, может быть, фабричный шаблон

Answer 5

Я бы использовал интерфейс и установил в вашем конфигурационном файле настройку, которая во время выполнения определяет, какой конкретный класс создать.