Контракт на услугу апкастинга

У меня есть служба WCF, которая предоставляет множество методов.

Мое приложение использует эту службу, а ServiceContract включает определения OperationContract только для некоторых методов.

Чтобы перейти к вопросу, рассмотрим следующий пример кода:

[ServiceContract]
public interface IServer
{
    [OperationContract]
    void BasicOperation();
}

[ServiceContract]
public interface IExtendedServer : IServer
{
    [OperationContract]
    void ExtendedOperation();
}

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

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

((IExtendedServer)channel).ExtendedOperation()

Когда я пытаюсь это сделать, я получаю сообщение об ошибке

System.InvalidCastException: невозможно привести прозрачный прокси-сервер к типу Contract.IExtendedServer.

Надеюсь, я не запутался ...


c# interface wcf wcf-client
person mr.b    schedule 04.06.2010    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Сервисы в мире SOA должны иметь четко определенный и довольно статичный интерфейс. Службы SOAP требуют представления в WSDL (и включенной или отдельной схемы XSD = XML для задействованных данных).

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

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

Итак, я бы сказал: если вам действительно нужна гибкость в услугах, вам нужно проверить сервисы на основе REST. SOAP не отвечает этим требованиям. Перейдите в Центр разработчиков REST WCF на MSDN, чтобы получить обширную информацию и ресурсы о том, как используйте REST в WCF и с ним.

person marc_s    schedule 04.06.2010
comment
+1 За конкретную альтернативу с продуманными рассуждениями. - person David; 04.06.2010
comment
Спасибо. Я был немного расплывчатым в своих рассуждениях, имел какое-то представление, но, похоже, оно не прижилось, особенно после хорошего объяснения. - person mr.b; 05.06.2010

arrow_upward
0
arrow_downward

Я не уверен, чего вы здесь пытаетесь достичь. Вы имеете дело с сервисами, у которых есть конечные точки, предоставляющие определенные контракты (то есть интерфейсы). Вы имеете дело не с объектами, кастингами и тому подобным; это не сработает и в любом случае неправильный подход.

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

person tomasr    schedule 04.06.2010