简化服务器和客户端上的 WCF 配置

Question

我们正在将旧版 .Net Remoting 服务迁移到 WCF。在阅读了一段时间后，我偶然发现了这个元数据谈话并在客户端上动态构建代理：看起来很有希望。

如果可能的话，我想要实现的是在一个 Web 应用程序上以最少的配置公开服务（即，配置文件中没有显式的 <services> 节点），并在客户端中构建代理（通过共享接口）也只需最少的配置。

我知道默认情况下可以公开所有服务的元数据，但这似乎是无用的，因为它为每个服务生成不同的 url，然后我需要在我的客户端上维护几十个硬编码字符串.

这是我当前的配置文件：

<system.serviceModel>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />

  <behaviors>
    <serviceBehaviors>
      <behavior>
        <serviceMetadata httpGetEnabled="true" />
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

我想在服务器上有一个单一的 URL（可能是基地址本身，'http://localhost/VirtualDir'）并使用这个端点自动解析来自客户端的任何服务接口。我遇到了this somewhat old post，这或多或少是我想要实现的。当时，似乎没有任何方法可以优雅地做到这一点。

难道没有办法在服务器上公开单个 MEX 端点，然后解析其上的任何合约接口吗？这样我就可以：

1. 在客户端存储单个 URL
2. 使用给定接口的MetadataResolver 类检索端点
3. 使用解析的端点使用ChannelFactory<T> 创建代理

我想在某种工厂类中执行此操作，并将其与 Unity IoC 容器一起使用。

我认为我仍然可以使用某种约定来完成这项工作，以使用已知格式构建许多真实的端点地址。不过我想避免这种情况，因为它仍然会导致问题。

Answer 1

我可以想到两种方法来解决这个问题：

1. 使用 WCF 路由服务并使用 filters 根据肥皂动作或其他内容进行路由。
2. 创建一个端点来处理请求中的Message 实例，然后在内部处理convert 它们。

WCF 路由的缺点是它本身就是另一个 WCF 服务。而且我不确定选项 2 是否完全符合您的描述。

检查此MSDN magazine article。

此外，MetadataResolver 主要用于客户端在调用服务之前动态解析服务上的端点。正如您所描述的，我之前没有在服务端看到过这种情况。

此外，还有一个小问题，WCF 旨在用于定义两个应用程序通信所跨越的显式边界。这种分离是明确的，并表示为对抽象的、冗长的外部合同的相互接受。在我看来，试图摆脱这种明确的契约会让人质疑为什么你首先需要边界。如果可以的话，调用进程内运行的服务几乎总是更好。