WCF и наследование интерфейса - это ужасная вещь?

Question

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

public interface IBasicCalculator
{
    int Add( int a, int b );
}

public interface IFloatingPointCalculator
{
    double Add( double a, double b );
}

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

Итак, я понял, что мне нужно представить «комбинированный» интерфейс (можно также назвать его фасадом), например:

[ServiceContract]
public interface ICalculatorService : IBasicCalculator, IFloatingPointCalculator
{
    [OperationContract(Name = "AddInt")]
    new int Add( int a, int b );

    [OperationContract(Name = "AddDouble")]
    new double Add( double a, double b );
}

Если я делаю это, то WCF предоставляет клиенту оба метода, которые могут их вызывать, и все это на самом деле работает.

Однако «наследование интерфейсов», как это, кажется неуклюжим. Особенно new int Add и new double Add. Строго говоря, new для метода означает скрытие базового метода, чего я на самом деле не делаю вообще. Я могу опустить new, но тогда я просто получаю предупреждения компилятора, которые равняются «Я думаю, что я скрываю этот метод, вам нужно переименовать его или добавить к нему« новый »».

Итак, это вопрос из двух частей:

1. Идет ли я в ногу со своей логикой «объединить все в один интерфейс», или на самом деле есть способ раскрыть «подуслуги» или «несколько связанных служб» с помощью WCF?

2. Если это то, что нужно сделать, есть ли лучший способ?

Спасибо!

Answer 1

Я только что понял, что вы можете выставлять несколько конечных точек (каждая из которых использует свой интерфейс) для одной и той же службы, и вам все еще нужно только создать ОДНУ прокси-библиотеку на клиенте, которая дает доступ ко всем из них, что полностью решает мою проблему .

Answer 2

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

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

Answer 3

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

WCF, безусловно, делает возможным поддержку нескольких конечных точек, которые взаимодействуют с использованием уникальных URI и независимых контрактов. Однако тот факт, что класс ClientBase принимает только один тип интерфейса контракта, например, в значительной степени подразумевает, что прокси-классы, даже если они хранятся в одной и той же библиотеке, все равно должны четко реализовывать только один интерфейс контракта.

Если вы действительно успешно создали только одно определение прокси-класса, я хотел бы знать, как вам удалось это сделать. Возможно, я неправильно понимаю ваши потребности. Реализация различных прокси-классов дает вам максимальную гибкость, поскольку значения OperationContractAtrribute, такие как IsInitiating и IsTerminating, вероятно, будут разными для разных контрактов. Объединение интерфейсов двух контрактов, как в вашем примере, потенциально меняет способ, которым вы бы приписывали методы в контракте на обслуживание.