强制.NET Web服务使用本地对象类，而不是代理类

Question

我有一个从 Windows 窗体应用程序（都是 .NET，都在同一个解决方案中）调用的 Web 服务，并且我希望我的 Web 服务从项目中的其他位置返回自定义对象 - 这是它们的常见对象两者共享一个引用，因为它位于我的解决方案中的第三个项目中。 当我调用 Web 服务时，它返回一个“Person”对象，但它位于 Web 服务的命名空间中，并且是从 Web 服务本身生成的代理类创建的。 因此，我无法操作它并将其返回给我的程序，该程序需要一个基于类的共享副本的“Person”对象，而不是来自 webservice 命名空间的代理副本，并且当我尝试时会收到错误将其 CType 为正确的类类型。

如何强制 Web 服务使用类的本地副本，而不是代理副本？ 我的问题在这种情况下有意义吗？ 如果没有，我会澄清。

值得注意的是 - 我已经采用 ByRef 传递所有参数，并使用这些返回值来填充我在返回时创建的对象的副本。 这不是最好的方法！

Answer 1

如果使用 svcutil.exe 生成 WCF 客户端代理，则可以在命令行上使用 /reference 来指定包含公共类的程序集。 Svcutil 应重用该类定义，而不是在服务代理命名空间中生成新的类定义。

另外，只有当您的公共类可序列化并按值传递时（即它作为数据契约公开，而不是作为服务契约公开），这才有效。

Answer 2

根据设计，客户端生成的代理对象（或类）与服务器端相应 Web 方法使用的对象不同（尽管相同）。

例如，当服务器端序列化 & 时， 返回一个对象A，它将被接收& 在客户端反序列化生成的相应对象 B 中，该对象 B 具有与对象 A 相同的结构（相同的成员、相同的子类等），但在特定于客户端 Web 服务引用的不同命名空间内< /strong> 并且可能有不同的名称。 这是有充分理由的，但这里没有必要讨论它。

正如线程前面指出的，围绕对象 A 可能开发了很多有用的代码，但遗憾的是重新实现它（或简单地重复源代码）。 此外我们希望尽可能避免代码重复，以方便进一步的维护。

从长远来看，在客户端存根（soap 客户端）自动生成的反序列化中进行摆弄的解决方案风险更大，因为它要求您对每个后续客户端存根与每个新版本的重新同步应用相同的操作服务器端的。 此外，据我所知，在 2008 年的某个时候，这是可能的，但是我们有什么保证它将继续以与后续 Visual Studio 版本相同的方式工作呢？ 我无法在 VS2019 中做到这一点。

对于像我这样懒惰（且谨慎）的人来说，有一个简单（且安全）的解决方案； 方法是这样的：

客户端存根收到对象B（对应服务器端的对象A）后，可以快速将其“转换”回对象A。只需从其中进行“深复制”即可对象A到对象B！ 如果对象 A（和 B）足够复杂，您可能会考虑使用“System.Reflection”进行通用深度复制，以按名称匹配每个子字段，或者您可以使用通用序列化器/反序列化器将接收到的对象 B 转换为文本，然后将此文本转换回对象 A。例如，我使用 Newtonsoft Nuget 包用几行代码完成了这项工作。

请参阅以下示例，在服务器端的 .asmx 服务的页面中：

    [WebMethod]
    public ObjectTypeA WebMethodPeek()
    {
        ObjectTypeA instanceA = GetSerializableObjectA();
        return instanceA;
    }

而在 Web 服务客户端：

    using Newtonsoft.Json;

    public ObjectTypeA Peek()
    {
        SoapClient cli = new SoapClient("my-end-point-name");
        ObjectTypeB instanceB = cli.WebMethodPeek();
        string text = JsonConvert.SerializeObject(instanceB);
        ObjectTypeA instanceA = JsonConvert.DeserializeObject<ObjectTypeA>(text);
        return instanceA ;
    }

感谢 Enrique Reyes 他在这篇文章中提供了简单而优雅的“DeepCopy”答案 如何在C#.NET中不同类型的对象之间进行深度复制）

写完这个答案后，我发现同样的策略（......不知怎的，没有太多强调）也在这篇文章中以不同的方式解释了 使用不同类型序列化/反序列化 System.Object

Addemdum

经过一些动手工作后，我发现这种方法没有什么可克服的烦恼使用此“JSon 序列化/反序列化”来执行相同（或几乎）数据结构的深层复制。

1. 对于具有许多子类和属性的大型对象，预计会有更大的占用空间。 在客户端添加 Web 服务引用时，它不仅会复制 Web 方法参数的结构层次结构（具有不同的命名空间），而且如果用作返回类型，还会复制另一个结构层次结构。 算上原始的（通过公共项目库共享），我们最终得到了相同大型可序列化结构的 3 个副本。

2. 然后我遇到了多态子类的障碍，它使反序列化器感到困惑。 这是因为，就我而言，它们被松散地键入为“对象”，以便保存不同的派生类，而不管它们的类型。 在这种情况下，我们仍然可以编写一组回调函数来在从 JsonConverter 派生的类中完成修补工作。 在服务器端绝对不需要做任何事情。

但总体而言，尽管交换的对象体积庞大且复杂，但一切都很顺利。 我仍然使用 xsd.exe 为更大、更复杂的对象生成完全可序列化的类。

另一种更简单的策略：使用二进制序列化

后来我发现仅涉及 .NET Framework 来交换二进制对象（即 byte[]）简单得多。 它允许在服务器端和客户端之间使用通过公共库共享的相同类。 在任何一方，我们都需要在发送之前序列化并反序列化我们收到的内容。

我编造了一些非常简单的例子，省略了理解所不需要的内容。

• 所需的命名空间：

   使用 System.IO； 
     使用 System.Runtime.Serialization.Formatters.Binary； 
    

• 客户端从服务器接收的示例：

   SharedClass myClass = null; 
     byte[] byteArray = my_WebService.GetInfo(); 
     BinaryFormatter 格式化程序 = new BinaryFormatter(); 
     使用（MemoryStream流=新MemoryStream（byteArray））{ 
         对象 obj = formatter.Deserialize(stream); 
         myClass = obj 作为 SharedClass ； 
     } 
    

• 客户端发送到服务器的示例：

   byte[] byteArray = null; 
     SharedClass myClass = new SharedClass(xyz); 
     BinaryFormatter 格式化程序 = new BinaryFormatter(); 
     使用 (MemoryStream 流 = new MemoryStream()) { 
         格式化程序.Serialize(stream, myClass); 
         byteArray = Stream.ToArray(); 
     } 
     my_WebService.SendInfo(byteArray); 
    

在服务器端，这几乎是相同的事情

• 服务器发送到客户端：

  <前><代码> [WebMethod]
  公共字节[] GetInfo()
  {
  SharedClass myClass = new SharedClass(xyz);
  BinaryFormatter 格式化程序 = new BinaryFormatter();
  使用 (MemoryStream 流 = new MemoryStream()) {
  格式化程序.Serialize(stream, myClass);
  返回 (stream.ToArray());
  }
  }

• 服务器从客户端接收：

  <前><代码> [WebMethod]
  公共无效SendInfo（字节[] byteArray）
  {
  SharedClass myClass = null;
  BinaryFormatter 格式化程序 = new BinaryFormatter();
  使用（MemoryStream流=新MemoryStream（byteArray））{
  对象 obj = formatter.Deserialize(stream);
  myClass = obj 作为 SharedClass；
  }
  }

这工作很快，不需要太多工作。 但是：

• 确保共享结构始终是相同的版本（或者更准确地说：只是相同），否则反序列化将中断
• 如果反序列化不中断。 即使从受信任的用户接收数据，仍然进行最低限度的数据完整性验证。 寻找“超出范围”的值、损坏的日期等
• 安全方面的信息。 出于安全原因，许多人不愿意（常常惊慌失措）通过网络服务以二进制形式交换数据。 这始终取决于您如何处理接收到的数据。 如果你只是按原样保存二进制博客，确实令人担忧。 但如果它是结构化数据，则可能完全无关，即分解为较小的数据元素并重新组装成结构化对象。 因此，非法数据甚至很可能无法通过基本类型验证。 在最坏的情况下，您最终会得到一些损坏的“有效”数据，这些数据无论如何都是从善意的受信任用户那里获得的。
• 话虽如此，Web 服务应该有最低限度的访问控制：防火墙、IP 过滤、用户名/密码等

Answer 3

如果您使用 WCF，那么在客户端和使用者之间使用相同的数据契约和服务接口是相当容易的。 您可以在生成的代理类中进行编译并修改它以使用正确的命名空间，或者使用 ChannelFactory 类为您创建动态代理。

第一种解决方案非常脆弱，并且会导致每次服务接口发生变化时都需要修改代理类。 第二种技术效果相当好，我们在我之前从事的项目中使用过。 使用这两种方法中的任何一种，您都需要确保所有调用者都保持最新版本的界面。

从您描述问题的方式来看，听起来您希望服务和客户端共享同一个实例。 由于 WCF 在将类型发送到服务或从服务发送出类型时对类型进行序列化和反序列化，因此您必须做一些更聪明的事情。 这是你的意思吗？

Answer 4

我不确定，但是当您编译 .NET Web 服务时，它会创建一个 DLL 文件，您可以尝试在本地使用该文件。 但是，当我构建面向服务的应用程序时，我会在解决方案中创建不同的层，例如数据访问层、逻辑层、服务层、UI 层、控制器层，例如在控制器层中，我将执行一种用户身份验证方法，即与数据访问层和逻辑层连接，然后我将在服务层调用该方法，我也可以在 UI 层调用它，如果我从 UI 层调用它，当我想使用它时，它会在本地调用从服务层，我将使用该方法创建一个 Web 方法，该方法将返回 bool 或用户名等。