服务器和客户端上的简化WCF配置
我们正在将遗留.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 '），并使用此端点自动解析来自客户端的任何服务接口。 我遇到了这个有点旧的帖子，这或多或少是我想达到的。 当时，似乎没有任何方法可以优雅地做到这一点。
没有办法在服务器上公开单个MEX端点，然后解决其上的任何合同接口？ 这样我就能够：
MetadataResolver类为给定接口检索端点 ChannelFactory<T>创建代理 我想在某种工厂类中做到这一点，并将其与Unity IoC容器一起使用。
我想我仍然可以使用某种惯例来完成这项工作，以使用已知格式构建许多真实的端点地址。 我想尽量避免这种情况，因为它仍然会导致问题。
我可以通过两种方式来思考如何处理这个问题：
WCF路由的缺点是，这本身就是另一个WCF服务。 而且我不确定选项2是否可能完全如你所描述的你想要的。
查看MSDN杂志文章。
此外，MetadataResolver主要用于客户端在调用服务前动态解析服务上的端点。 正如你所描述的，我没有在服务端看到过这一点。
此外，还有一个小点，WCF旨在用于定义两个应用程序通信的显式边界。 这种分离是明确的，并表达为相互接受抽象的，详细的外部合同。 在我看来，试图摆脱这种明确的契约会让人质疑为什么你首先需要边界。 如果可以的话，调用正在运行的服务几乎总是更好。
链接地址: http://www.djcxy.com/p/92425.html