ASMX 对 SoapHeader 使用编译类型而不是生成类型

发布于 2024-10-05 19:27:42 字数 1233 浏览 8 评论 0原文

我对肥皂头的研究不多，所以我希望这里有答案。这是我想要实现的目标的一个简单示例。

我有一个 ASMX Web 服务和一个客户端，以及一个共享 DLL。在shared.dll 中，我有一个可序列化的类型，我们将其称为CustomHeader，派生自SoapHeader。有一个 Web 方法通过 SoapHeader 属性接受此输入作为输入，因此我的服务如下所示：

[WebService]
public class MyService : WebService {
    public CustomHeader MyCustomHeader { get; set; }

    [WebMethod]
    [SoapHeader("MyCustomHeader", Direction = SoapHeaderDirection.In)]
    public void Go() { }
}

到目前为止，一切都很好。在 Go() 方法中，我可以访问 MyCustomHeader 对象并使用它执行操作。从客户端，当我生成代理时，生成的代码包括一个包含 MyService 对象的数据属性的 CustomHeader 类，以及一个名为 CustomHeaderValue 的属性，我可以在对 Go() 进行服务调用之前在客户端上设置该属性，以及它传递得很好。

问题在于原始 CustomHeader 类具有有助于填充数据字段（哈希函数、计算值等）的构造函数和方法。由于客户端具有对共享库的引用，因此客户端可以创建原始 CustomHeader 类的实例，但它不能在服务调用中使用该对象，因为它在技术上是不同的类型。

我可以想到几种处理此问题的方法：

1) 通过一次拉取一个属性，将 CustomHeader 对象转换为生成的 CustomHeader 类。这不会进行太多处理，但这意味着我要么需要使用反射来循环访问属性，要么在 CustomHeader 类发生更改时触摸转换代码。

2) 序列化 CustomHeader 对象，然后将其反序列化到生成的 CustomHeader 类中 - 因为除了构造函数和方法之外它们实际上是相同的，所以序列化应该可以正常工作。这将是最简单的方法，但它需要一轮额外的序列化/反序列化，虽然不是非常昂贵，但仍然是额外的处理。

3）修改生成的代码，使CustomHeaderValue属性为我的共享类型而不是生成的类型。我的观点是，这是一种可怕的做事方式，但它可能是这些选项中最便宜的。我不会做这个选项，但我只是想把它放在那里，因为从技术上讲它是可行的。

我错过了什么吗？这样做有公认的模式吗？

感谢您的帮助。

原文

I haven't worked much with soap headers, so I'm hoping there's an answer here. Here's a simple example of what I'm trying to accomplish.

I have an ASMX web service and a client, along with a shared DLL. In shared.dll, I have a serializable type, let's call it CustomHeader, deriving from SoapHeader. There's a web method that accepts this as input via a SoapHeader attribute, so my service looks like:

[WebService]
public class MyService : WebService {
    public CustomHeader MyCustomHeader { get; set; }

    [WebMethod]
    [SoapHeader("MyCustomHeader", Direction = SoapHeaderDirection.In)]
    public void Go() { }
}

So far, so good. Inside the Go() method, I can access the MyCustomHeader object and do things with it. From the client, when I generate a proxy, the generated code includes a CustomHeader class containing the data properties of the MyService object, and a property called CustomHeaderValue, which I can set on the client before making the service call to Go(), and it passes it along just fine.

The issue is that the original CustomHeader class had constructors and methods that helped to populate the data fields (hash functions, calculated values, etc.). Since the client has a reference to the shared library, the client can create an instance of the original CustomHeader class, but it can't use that object in the service call, since it's technically a different type.

I can think of a few ways of handling this:

1) Convert the CustomHeader object to the generated CustomHeader class by pulling the properties over one at a time. This wouldn't be much processing, but it would mean that I'd either need to use reflection to loop through the properties, or touch the conversion code whenever the CustomHeader class changes.

2) Serialize the CustomHeader object, then deserialize it into the generated CustomHeader class - since they're really identical aside from the constructors and methods, the serialization should work just fine. This would be the easiest way, but it requires an extra round of serializing/deserializing, which, while not terribly expensive, is still additional processing.

3) Modify the generated code to make the CustomHeaderValue property of my shared type instead of the generated type. My opinion is that this is a horrible way of doing things, but it probably would be the least expensive of these options. I'm not going to do this option, but I just wanted to put it out there since technically it will work.

Am I missing something? Is there an accepted pattern for doing this?

Thanks for the help.

分享到QQ

分享到微博