Наследование службы WCF

Question

У меня есть ОЧЕНЬ сложный сервисный узел, который состоит из нескольких сервисов DUPLEX. Они обеспечивают немного общей функциональности (Connect, Disconnect, KeepAlive и т. Д.), Но кроме того, они обеспечивают очень специфическую функциональность.

Все мои сервисы наследуются от общего базового класса (абстрактного).

Таким образом, я также несу ответственность за часть клиентского приложения, и я хочу, чтобы административная бюрократическая обработка соединений, разъединения, поддержания контактов и повторного подключения (и т. Д.) Обрабатывалась в базовом классе, поэтому я может наблюдать принцип DRY И заставлять других разработчиков НЕ выполнять свою собственную обработку соединений.

Есть ли какой-либо способ показать WCF базовый класс службы, чтобы я мог создать общий класс-оболочку для бюрократической траты времени в клиентском приложении?

Я действительно не хочу, чтобы каждый разработчик будущих клиентских компонентов создавал свою собственную оболочку?

И, если вы позволите тираду:

Почему, почему, почему Microsoft так полностью negligient в отношении передовой практики и основных принципов развития чистого кода? Это то же самое, что и с этим материалом INotifyPropertyChanged, где каждый вынужден писать массы ненужного повторяющегося кода вместо того, чтобы иметь простой атрибут для уведомления свойств ...

Answer 1

Я не знаю, как это сделать несколько прокси-серверов WCF наследуются от общего базового класса. Вы можете вручную отредактировать код, созданный при добавлении ссылки на службу, но это не подходит для удобства обслуживания.

Но вы можете использовать несколько прокси-серверов с одним и тем же базовым интерфейсом, если вы разделяете контрактную сборку между клиентом и сервером. Затем вы можете написать вспомогательный класс на стороне клиента (возможно, используя методы расширения) для выполнения общих операций с базовым интерфейсом. Вы также можете поместить вспомогательный класс в общую сборку и повторно использовать его у нескольких клиентов.

Хотя я не работал с дуплексными связями, поэтому не уверен, что это вызывает осложнения.

Например, предположим, что у вас есть две службы Calculator и Echo, и каждый из них должен реализовать метод Keepalive. Можно определить три контракта сервисные интерфейсы:

[ServiceContract] 
public interface IStatefulService 
{ 
    [OperationContract] 
    void KeepAlive(int sessionID); 
} 

[ServiceContract] 
public interface ICalculator : IStatefulService 
{ 
    [OperationContract] 
    int Add(int a, int b); 
} 

[ServiceContract] 
public interface IEcho : IStatefulService 
{ 
    [OperationContract] 
    string Echo(string message); 
} 

Вы можете поставить интерфейсы контракта службы в общей библиотеке классов, которая разделяет как клиента, так и сервера.

На сервере у вас будет класс ServiceBase, который будет реализовывать IStatefulService и содержать код обработки keepalive. У вас будет конкретный CalculatorService, который происходит из ServiceBase и реализует ICalculator; и конкретный EchoService, который происходит из ServiceBase и реализует IEcho.

На клиенте вам понадобятся два прокси, по одному на услугу. Теоретически вы можете сгенерировать прокси, используя «добавить ссылку на службу», используя флажок «Использовать типы ссылок из ссылочных сборок», но у меня возникли проблемы с этим. Вместо этого, вы можете просто использовать ChannelFactory непосредственно, как это:

var echoer = (new ChannelFactory<IEcho>("")).CreateChannel(); 
Console.WriteLine(echoer.Echo("hello")); 

var calculator = (new ChannelFactory<ICalculator>("")).CreateChannel(); 
Console.WriteLine(calculator.Add(2, 3)); 

(В производстве код, вы хотите использовать заводы канала, а не создавать их на лету, как это и вы бы утилизировать. прокси, и у вас будет обработка ошибок ...)

Вам также необходимо настроить конечные точки в конфигурационном файле клиента.

Как только у вас есть два прокси-сервера, которые используют базовый интерфейс, вы можете написать класс утилиты, который поможет вам работать с этим интерфейсом.