我有一个名为:
的名称空间的WCF服务MyCompany.MyApplication.Configuration.ConfigurationHelperService
在客户端,我有一个名为的程序集,它使用这项服务:
MyCompany.MyApplication.Core (this is the default namespace)
当我添加服务引用时,我要求在添加服务引用对话框中指定的命名空间最终会在客户端程序集命名空间的末尾添加:
MyCompany.MyApplication.Core.MyCompany.MyApplication.Configuration
.ConfigurationHelperService
因为此时我被要求提供命名空间,所以指定远程服务命名空间的名称似乎很自然。即我想使用他们的命名空间MyCompany.MyApplication.Configuration.ConfigurationHelperService
来引用我的远程服务类,因为它们在技术上不属于客户端。
我的问题是:
我已经和它一起生活了很长时间(你对ASMX Web服务客户端有同样的问题),但是从未见过为什么Visual Studio(我想svcutil.exe
)以这种方式工作的书面解释。
答案 0 :(得分:1)
嗯,我认为你有两个选择:
如果你控制电线的两端,例如您编写服务器和客户端,您可以将所有共享项目(如服务合同,数据合同等)放入单独的程序集中,并在客户端和服务器之间共享。这样,任何事情都不会重复,并且通信的两端都会引用您选择的给定命名空间中完全相同的项目
习惯了这样一个事实:如果你在Visual Studio中添加一个WCF服务引用,你基本上会得到一大堆重复 - 因为如果你没有控制通信的两端,那就是全部WCF可以继续 - 服务和客户端之间交换的元数据(通过服务上的WSDL或MEX端点)。而且由于这显然是客户端的一部分,它完全独立于服务(它们共享的所有内容,通常是XML模式中定义的有线格式 - 没有别的),它的命名空间也将面向客户端。我认为这是一个(好的)功能,而不是我试图打击的......
默认情况下,在使用WCF的SOA世界中,客户端和服务完全独立。两者之间没有“远程对象”连接或类似的东西:客户端代理发生方法调用,捆绑传入的参数以及服务器上要调用的一些信息,并将其全部序列化为序列化消息(阅读:文本/ XML消息,基本上)。该消息通过线路发送到服务器,然后服务器处理该消息并返回响应。
所以这是不只是一个.NET函数调用或者其他东西 - 你的系统的那两个部分(默认情况下)完全相互独立。考虑到这一点,至少对我而言,将客户端所做的一切都放在客户端的命名空间中是有道理的 - 毕竟,服务器可能是完全不同的东西,比如Java,PHP,IBM大型机 - 你通常没有任何线索是什么(并且不需要)。