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

м приложении есть 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, но затем я просто получаю предупреждения компилятора, которые равняются «Я думаю, что я скрываю этот метод, вам нужно переименовать его в метод или добавить в него« новый »».

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

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

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

Спасибо!

Ответы на вопрос(3)

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

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

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

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

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

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

 EnocNRoll - Ananda Gopal23 янв. 2009 г., 23:07
Между прочим, я использую интерфейс маркера в качестве основы для всех моих контрактов с данными. Это позволяет мне в общих чертах иметь дело с контрактами данных в моей структуре WCF.
 EnocNRoll - Ananda Gopal26 янв. 2009 г., 21:47
Круто, так что вы реализуете более одного контракта на обслуживание одного сервиса. Круто, так что это означает, что ваша точка отсчета никогда не касалась количества прокси-серверов, а действительно количества сервисов, и теперь вы знаете, как выполнить то, что вы описываете. Здорово.
 Orion Edwards26 янв. 2009 г., 21:36
Я просто использовал инструмент Visual Studio «Добавить ссылку на службу» - он генерировал одну клиентскую библиотеку - в этой библиотеке был один прокси-класс на конечную точку (следовательно, много классов в одной библиотеке), но все классы «прокси» отключались от одной. объект на сервере, поэтому не имеет значения, что они отдельно

Ваш ответ на вопрос