上播ServiceContract

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的服务。肥皂不符合那个要求。访问MSDN上的WCF REST开发者中心，获取关于如何在WCF中和与WCF一起使用REST的大量信息和资源。

Answer 2

我不知道你想在这里完成什么。您正在处理服务，这些服务具有暴露特定契约(即接口)的端点。您不是在处理对象和强制转换之类的问题；它不会工作，也不是正确的方法。

在我看来，您所拥有的确实是这样的:一个服务，它公开一个具有一组公共操作的端点，并可能使用其他扩展操作的附加端点数目。您仍然可以在服务端拥有一个服务类，但就客户端而言，它们只是不同的端点/服务。