Web 服务 - Xml 包含在派生类而不是基类中？
我使用抽象类作为 Web 服务调用中的参数。 目前，我在基类中包含派生类的 XmlInclude，如下所示：
[XmlInclude(typeof(DerivedClass))]
public abstract class BaseClass
{
}
但是，我不想在基类中包含所有派生类型。
在 http://www.pluralsight.com /community/blogs/craig/archive/2004/07/08/1580.aspx，作者提到了一种替代方法 - 将属性写在 Web 方法上方，如下所示：
[WebMethod]
[System.Xml.Serialization.XmlInclude(typeof(DerivedClass))]
public BaseClass getClass() {
return new DerivedClass();
}
但是，我也不想这样做将派生类型放入 Web 服务中。 有没有办法将属性保留在派生类型中？
I am using an abstract class as a parameter in a web service call. Currently, I am including an XmlInclude of a derived class in the base class, like so:
[XmlInclude(typeof(DerivedClass))]
public abstract class BaseClass
{
}
However, I'd rather not include all of the derived types in the base class.
In http://www.pluralsight.com/community/blogs/craig/archive/2004/07/08/1580.aspx, the author mentions an alternative - writing the attribute above the web method instead, like so:
[WebMethod]
[System.Xml.Serialization.XmlInclude(typeof(DerivedClass))]
public BaseClass getClass() {
return new DerivedClass();
}
However, I'd also like to not put the derived types in the web service either. Is there a way of keeping the attribute in the derived type?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
让我们假定，当反序列化发生时，框架需要以某种方式知道类型层次结构中有哪些类型，以及这些类型如何在 xml 中表示。 如果该信息存储在派生类型中，它确实无法推断出该信息。
然后你有几个选择：
- 使用 XmlIninclude 属性
- 在 XmlSerializer 构造函数重载中指定允许的类型集
现在，如果您希望将子类传递到 Web 服务，则 Web 服务器将控制序列化和反序列化。 因此 XmlSerializer 构造函数不再是一个选项。
正如你所说，你可以将属性放在 webservice 方法上，而不是直接放在类上。 在保持类“纯粹”和记住将这些属性放在可能需要的每个位置之间需要进行权衡。
当然，真正的问题似乎是您正在尝试使用业务对象作为 Web 服务层中的消息格式。
如果您确实想将“消息格式”和“业务对象”职责分开，那么可以使用另一个类（具有完整的层次结构），其唯一用途是用作 Web 服务参数。 在这种情况下，将所需的所有 XmlInclude 属性粘贴到基类上是没有问题的。 然后，在调用 Web 服务时，根据消息格式对象调整您的业务对象。 这为您带来了额外的好处，即不对参数类型应用 Web 服务类型约束（例如，没有接口作为参数）。
当然，这种方法不太方便。
最后，Web 服务需要知道需要什么类型，否则它将无法正确地序列化和反序列化它们。
是的，这是一个冗长的解释，解释了为什么答案是否定的，你不能只将属性保留在派生类型中。 但我很愿意错:)
Lets take it as a given that the framework would somehow need to know what types are in the type hiearchy when deserialization occurs, and how those types are represented in xml. It really has no way to infer this information if it is stored in a derived type.
You then have a couple of options:
- use the XmlInclude attribute
- specify the set of allowed types in the XmlSerializer Constructor overload
Now, if you're expecting a subclass to be passed in to the webservice, the webserver controls serialization and deserialization. So the XmlSerializer contstructor is no longer an option.
As you say, you can put the attribute on the webservice method instead of directly on the class. There's a trade-off between keeping your class "pure" and remembering to put those attributes in every place they may be required.
Of course, the real problem appears to be that you are trying to use your business objects as the message format in your webservice layer.
If you really want to keep the "message format" and "business object" responsibilities separate, then have another class (with the full hierarchy) for which the only use is to be used as a webservice parameter. In that case, there's no problem with sticking all the XmlInclude attributes you need, on the base class. Then, when making calls to the webservice, adapt your business object to and from the message format object. This gives you the added benefit of not applying webservice type constraints to the types of your parameters (eg no interfaces as parameters).
Of course, this method isn't as convenient.
In the end, the webservice needs to know what types to expect, or it won't be able to serialize and deserialize them properly.
And yes, this is a long winded explanation of why the answer is no, you can't only keep the attribute in the derived type. I'd love to be wrong though :)
我不明白在这种情况下如何。 如果要反序列化，则会出现用于指定额外类型数组的重载，您可以在其中传递派生类型。
I don't see how in this case. If you are deserializing there is an overload for specify extra types array where you pass in the derived types.