在服务器和客户端简化WCF配置 [英] Simplified WCF configuration on server and client

问题描述

我们都在为WCF迁移旧NET远程服务的过程。读了一会儿主题后，我偶然发现了这个元数据说话，建设代理的客户端动态的：它似乎有前途的。

We are in the process of migrating legacy .Net Remoting services to WCF. After reading on the subject for a while, I stumbled upon this metadata talk and building proxies dynamically on the client: it seemed promising.

我想实现的，如果可能的话，是揭露这些服务上的一个web应用以最小的配置（即没有明确的＆LT;服务＆GT;在配置节点文件），并建立在客户端的代理（用最少的配置共用接口）也。

What I wanted to achieve, if possible, is to expose the services on one web application with minimal configuration (i.e., no explicit <services> node on the config file), and build the proxies in the client (by sharing the interface) also with minimal configuration.

我知道这是可能暴露元数据的所有服务在默认情况下，但这似乎工作方式是没用的，因为它会产生不同的URL为每个服务，我会再需要保持几十个硬codeD我的客户端的字符串。

I know it is possible to expose metadata for all services by default, but the way this seems to work is useless, since it generates different urls for each service, and I would then need to maintain dozens of hardcoded strings on my client.

这是我目前的配置文件：

This is my current config file:

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

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

我想在服务器上单个URL（也许是基址本身，'的http：//本地主机/ VirtualDir ），并使用该终端自动解决从客户端的任何服务接口。我碰到<一href="http://social.msdn.microsoft.com/Forums/vstudio/en-US/62b4462f-5a40-4874-89c9-b6d99c6521c5/wcf-4-simplified-client-configuration"相对=nofollow>这个有点老帖子，这是多了还是少了什么，我想实现的。当时，似乎没有任何办法做到这一点优雅。

I wanted to have a single URL on the server (perhaps the base address itself, 'http://localhost/VirtualDir') and use this endpoint to automatically resolve any service interface from the client. I came across this somewhat old post, which is more or less what I would like to achieve. At the time, there seemed to not be any way to do that gracefully.

有没有一种方法，也许暴露服务器上的单个MEX端点，然后解决任何协定接口就可以了？这样，我就可以：

Isn't there a way to perhaps expose a single MEX endpoint on the server, and then resolve any contract interface on it? This way I would be able to:

1. 存储单个URL在客户端上
2. 使用 MetadataResolver 类给定接口
3. 使用 的ChannelFactory＆LT; T＆GT; 使用解决端点

我想里面的一些工厂类做到这一点，并用它与统一的IoC容器。

I wanted to do this inside some kind of factory class, and use it with the Unity IoC container.

我想我可以用某种约定的建设使用已知的格式很多实际的端点地址仍使这项工作。我想避免，虽然，因为它仍然可以引发问题。

I think I can still make this work using some kind of convention to build the many real endpoint addresses using a known format. I would like to avoid that though, since it can still lead to problems.

推荐答案

有两种方式我能想到的你如何能接近这样的：

There are two ways I can think of how you could approach this:

1. 使用WCF路由服务，并采用过滤器路由基于SOAP动作，或其他内容。
2. 创建它处理讯息实例的端点，以及那么<一个href="http://msdn.microsoft.com/en-us/library/system.servicemodel.description.typedmessageconverter.frommessage.aspx"相对=nofollow>转换他们内部。

1. Use WCF Routing Service and employ filters to route based on soap action, or other content.
2. Create an endpoint which handles Message instances in the request, and then convert them internally.

的WCF路由的缺点是，这是另一种本身WCF服务。而且我不能肯定，如果你到底怎么描述你想要的选项2甚至有可能。

The drawback of WCF routing is that this is itself another WCF service. And I am not certain if option 2 is even possible exactly how you describe you want it.

勾选此 MSDN杂志文章。

此外MetadataResolver主要是使用在客户端调用之前动态地解决在服务端点。我还没有看到你描述在此之前实施的服务端。

Also MetadataResolver is primarily for use on the client to dynamically resolve endpoints on a service before calling them. I have not seen this implemented before on the service end as you describe.

此外，和一个小点，WCF被设计成用来定义明确的边界横过这两个应用程序进行通信。这种分离是pssed作为一个抽象的，详细的，对外承揽的相互认可明确，EX $ P $。为了试图摆脱这种在我看来，明确的合同会质疑为什么需要摆在首位的边界。这几乎总是最好打电话到服务，如果你能在进程内运行。

Additionally, and a minor point, WCF is designed to be used to define an explicit boundary across which two applications communicate. This separation is explicit and expressed as the mutual acceptance of an abstract, verbose, external contract. To attempt to get away from this kind of explicit contract in my opinion would call into question why you need the boundary in the first place. It's almost always better to make calls to services running in-process if you can.

这篇关于在服务器和客户端简化WCF配置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！