WCF串行次序问题 [英] WCF serialization order issue

查看:179
本文介绍了WCF串行次序问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

最近我添加了一个新的属性设置为DataContract,它打破了API,为Java客户端,因为解串器不承认新添加的属性。

Recently I added a new property to a DataContract, which broke the API for our Java clients because the deserializer did not recognize the newly added property.

解决这个显然是设置新属性的顺序属性,因此它最后出现在SOAP消息中,然后解串器将完全忽略它。

The solution to this apparently is to set the order attribute on the new property, so that it appears last in the SOAP message, then the deserializer will simply ignore it.

现在的问题是,这个新属性存在的基类,WCF总是先序列化的基类的属性,所以派生类的属性总是会出现的顺序属性的事后不管。

The problem is that this new property exists in the base class, and WCF always serializes the base class properties first, so the derived class properties would always appear afterwards regardless of the order attribute.

只有2种方式我能想到的解决这个问题是:

The only 2 ways I can think of to fix this are:

  1. 的属性和它的所有逻辑复制到每一个派生类
  2. 在编写自定义序列,将令全球的事情

第一溶液是最差的,但最简单的。二是更加困难和风险,但最好的。

First solution is the worst, but easiest. Second is much more difficult and risky, but the best.

是否有任何其他的方式,我可以处理这种情况?是否有可能迫使默认的WCF序列化处理订购不同?

Are there any other ways I can handle this situation? Is it possible to force the default WCF serializer to handle ordering differently?

谢谢!

推荐答案

现在,我已经走了第一个解决方案,通过简单地把基本属性的内部,并与新的关键字隐藏它的派生类,现在看来,在SOAP消息的结束。我没有测试过这还与客户,但会在这里更新一次,我有。

For now I've gone with the first solution, by simply making the base property internal, and hiding it in the derived class with the "new" keyword, and now it appears at the end of the SOAP message. I haven't tested this with the clients yet, but will update here once I have.

基类:

internal bool? MyNewProperty
{
    get;
    set;
}

派生类:

[DataMember(Order = 2)]
public new bool? MyNewProperty
{
    get { return base.MyNewProperty; }
    set { base.MyNewProperty= value; }
}

如果我们想添加一个新的属性,应该是向后兼容,订单属性应设置为3(最佳实践来增加与每个API更新)。

If we want to add another new property that should be backwards compatible, the Order attribute should be set to 3 (Best practice to increment with every API update).

更新:
即使我能得到的最后一个元素在SOAP消息中出现,它仍然是一个重大更改我们的一些谁是使用Axis2客户端,它不处理反序列化的新的无法识别的属性摆好,即使出现持续。相关SO问题<一href="http://stackoverflow.com/questions/17532353/axis2-avoid-unexpected-subelement-error-when-non-required-property-added-to-w">here.

UPDATE:
Even though I was able to get the element to appear last in the SOAP message, it is still a breaking change for some of our clients who are using Axis2, and it doesn't handle deserializing the new unrecognized property gracefully, even if it appears last. Related SO question here.

这篇关于WCF串行次序问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆