Апкастинг СервисКонтракт

Question

У меня есть служба 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'.

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

Answer 1

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

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

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

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

Answer 2

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

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