我正在构建一组共享公共数据合同（或者您喜欢的实体）的WCF服务。这些是使用DataContract和DataMember属性修饰的简单数据传输对象。我明确指定了名称和命名空间。在尝试遵循IDesign关于每个服务合同平均12个成员的建议的原则时，我将我的服务项目分解为多个服务。
我的数据合同是在一个单独的程序集中，如果他们使用.Net，我可以提供给我们的客户。他们可以告诉他们的服务引用在引用的程序集中重用类型。但是，如果他们不使用.net并且他们使用两个使用相同实体的服务，那么他们将会得到一个含糊不清的参考消息。如果我没有引用数据契约dll，我可以在Visual Studio中看到这一点。
我的问题是，我可以在我的服务中做些什么，或者他们可以在客户端应用程序中做些什么来解决数据合同来自哪个代理？
答案 0 :(得分：11)
介绍如何解决此问题的好文章。 Sharing DataContracts between WCF Services
答案 1 :(得分：2)
我还倾向于将我的所有数据合同保存在一个程序集中，该程序集由多个服务和众多客户端应用程序引用，这很好但我从未尝试过在.NET之外使用该服务。
了解他们使用什么技术来使用.NET以外的服务可能会有所帮助？是什么抛出了暧昧的参考信息？
答案 2 :(得分：0)
我碰巧有多个服务在我的目的上共享对象。我不确定你为什么会遇到这个问题。就我而言，我能够以这种方式访问对象。 。 。 。
SERVICE1 client = new SERVICE1（）
client.CommonLibrary.Address。 。 。
SERVICE2 client2 = new SERVICE2（）
client2.CommonLibrary.Address。 。 。
答案 3 :(得分：0)
这取决于他们在客户端使用的工具。例如，使用Axis2 for Java，wsdl2java工具可以使用-u开关共享类型。
how can I share proxy objects across multiple Axis2 web service clients?
答案 4 :(得分：0)
根据我的理解和使用WCF，只要完全限定名称相同且具有相同的数据成员，客户端应用程序使用的任何一个数据合同都无关紧要。在内部，它只是动态创建对象，并使用公共setter重新分配这些数据成员属性。
我认为更好的方法是重构您的数据合同，以便将多个服务中的所有通用内容放在一个程序集中并引用它们，因此无论使用多少服务，您都不会遇到这种模糊或冲突问题由客户端应用程序。
答案 5 :(得分：0)
我们不是通过Visual Studio助手生成服务代理，而是通过调用slsvcutil.exe（因为我们使用Silverlight）的自定义批处理文件生成服务代理。在那里，您可以使用/ n参数指定名称空间映射，如下所示：
"C:\Program Files (x86)\Microsoft SDKs\Silverlight\v5.0\tools\slsvcutil.exe "^
http://ServiceUrl/MyService.svc^
**/n:http://youruri.org/CustomerService/DataContracts,CLR.Namespace.CustomerService^**
/n:*,CLR.Namepsace.MyService^
/r:"%ProgramFilesFolder%\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Windows.dll"^
/ct:System.Collections.ObjectModel.ObservableCollection`1^
/edb^
因此，所有具有命名空间http://youruri.org/CustomerService/DataContracts的数据协定都生成到代理文件中的clr命名空间CLR.Namespace.CustomerService，依此类推。鉴于您已在同一代理程序集中预先生成此代理，您可以从第二个文件中删除整个命名空间，一切正常 - 我们为最后一步编写了一个小工具。所有其他合同命名空间都将生成到CLR.Namepsace.MyService namspace（请参阅星号，意味着全部捕获）
设置这个过程有点麻烦，因为你必须手工制作批处理文件，但一旦完成，它就能很好地工作。