我们正在将遗留的.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端点,然后解决其上的任何合同接口?这样我就可以:
MetadataResolver
类检索端点ChannelFactory<T>
创建代理
醇>
我想在某种工厂类中执行此操作,并将其与Unity IoC容器一起使用。
我想我仍然可以使用某种约定来使用已知格式构建许多真实的端点地址。我想避免这种情况,因为它仍然会导致问题。
答案 0 :(得分:1)
我可以通过两种方式思考如何解决这个问题:
WCF路由的缺点是这本身就是另一个WCF服务。而且我不确定选项2是否可能完全按照你描述的方式来实现。
MetadataResolver主要用于在客户端上调用服务端点之前动态解析端点。我没有在服务端看到这个实现,如你所描述的那样。
此外,还有一个小问题,WCF旨在用于定义两个应用程序通信的显式边界。这种分离是明确的,表达为相互接受抽象的,冗长的外部契约。在我看来,试图摆脱这种明确的合同会让人质疑为什么你首先需要边界。如果可以的话,几乎总是更好地调用在进程中运行的服务。