在前一篇文章中我曾经说过，现在正在做一个小小的框架以实现采用统一的API实现对上下文（Context）信息的统一管理。这个框架同时支持Web和GUI应用，并支持跨线程传递和跨域传递（这里指在WCF服务调用中实现客户端到服务端隐式传递），以及对上下文项目（ContextItem）的读写控制。关键就在于后面两个特性的支持上面，出现一个小小的关于序列化的问题。解决方案只需要改动短短的一行代码，结果却让我折腾了老半天。

一、问题重现

为了重现我实际遇到的问题，我特意将问题简化，为此我写了一个简单的例子（你可以从这里下载）。在下面的代码片断中，我创建了一个名称为ContextItem的类型，代表一个需要维护的上下文项。由于需要在WCF服务调用实现自动传递，我将起定义成DataContract。ContextItem包含Key，Value和ReadOnly三个属性，不用说ReadOnly表示该ContextItem可以被修改。注意Value属性Set方法的定义——如果ReadOnly则抛出异常。

   1: [DataContract(Namespace = "http://www.artech.com")]

   2: public class ContextItem

   3: {

   4:     private object value = null;

   5:     [DataMember]

   6:     public string Key { get; private set; }

   7:     [DataMember]

   8:     public object Value

   9:     {

  10:         get

  11:         {

  12:             return this.value;

  13:         }

  14:         set

  15:         {

  16:             if (this.ReadOnly)

  17:             {

  18:                 throw new InvalidOperationException("Cannot change the value of readonly context item.");

  19:             }

  20:             this.value = value;

  21:         }

  22:     }

  23:     [DataMember]

  24:     public bool ReadOnly { get; set; }

  25:     public ContextItem(string key, object value)

  26:     {

  27:         if (string.IsNullOrEmpty(key))

  28:         {

  29:             throw new ArgumentNullException("key");

  30:         }

  31:         this.Key = key;

  32:         this.Value = value;

  33:     }

  34: }

为了演示序列化和反序列化，我写了如下两个静态的帮助方法。Serialize和Deserialize分别用于序列化和反序列化，前者将对象序列成成XML并保存到指定的文件中，后者则从文件读取XML并反序列化成相应的对象。

   1: public static T Deserialize<T>(string fileName)

   2: {

   3:     DataContractSerializer serializer = new DataContractSerializer(typeof(T));

   4:     using (XmlReader reader = new XmlTextReader(fileName))

   5:     {

   6:         return (T)serializer.ReadObject(reader);

   7:     }

   8: }

9:

  10: public static void Serialize<T>(T instance, string fileName)

  11: {

  12:     DataContractSerializer serializer = new DataContractSerializer(typeof(T));

  13:     using (XmlWriter writer = new XmlTextWriter(fileName, Encoding.UTF8))

  14:     {

  15:         serializer.WriteObject(writer, instance);

  16:     }

  17:     Process.Start(fileName);

  18: }

我们的程序很简单。从如下的代码片断中，我们先创建一个ContextItem对象，然后将ReadOnly属性设置成true。然后调用Serialize方法将对象序列化成XML并保存在一个名称为context.xml的文件中。然后调用Deserialize方法，读取该文件进行反序列化。

   1: static void Main(string[] args)

   2: {

   3:     var contextItem1 = new ContextItem("__userId", "Foo");

   4:     contextItem1.ReadOnly = true;

   5:     Serialize<ContextItem>(contextItem1, "context.xml");

   6:     var contextItem2 = Deserialize<ContextItem>("context.xml");

   7: }

序列化操作能够正常执行，但当程序执行到Deserialize的时候抛出如下一个InvalidOperationException异常。

二、问题分析

从上面给出的截图，我们不难看出，异常是在给ContextItem对象的Value属性赋值的时候抛出的。如果对DataContractSerializer序列化器的序列化/反序列化规则的有所了解的话，应该知道：对于数据契约（DataContract）基于属性（Property）的数据成员（DataMember），序列器在反序列化的时候是通过调用Set方法对其进行初始化的。在本例中，由于ReadOnly是True，在对Value进行反序列化的时候必然会调用Set方法。但是，只读的ContextItem却不能对其赋值，所以异常抛出。

那么，如何来解决这个问题呢？我最初的想法是这样：在序列化的时候将ReadOnly属性设置成False，然后添加另一个属性专门用于保存真实的值。在进行反序列的时候，由于ReadOnly为false，所以不会出现异常。当反序列化完成之后，在将ReadOnly的初始值赋上。虽然上述的方案能够解决问题，但是为此对ContextItem添加一个只在序列化和反序列化的过程中在有用的属性，总觉得很丑陋。

我们不妨换一种思路：异常产生于对Value属性凡序列化时发现ReadOnly非True的情况。那么怎样采用避免这种情况的发生呢？如果Value属性先于ReadOnly属性被序列化，那么ReadOnly的初始值就是False，这个问题不就解决了吗？这就是我们的第一个解决方案。

三、解决方案一：通过控制属性反序列化顺序

那么，如果控制那么属性先被反序列化，那么后被序列化呢？这就是要了解DataContractSerializer序列化器的序列化和发序列化规则了。在默认的情况下，DataContractSerializer是按照数据成员的名称的顺序进行序列化的。这可以从生成出来的XML的结构看出来。而XML元素的先后顺序决定了反序列化的顺序。

   1: <ContextItem xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.artech.com">

   2:     <Key>__userId</Key>

   3:     <ReadOnly>true</ReadOnly>

   4:     <Value xmlns:d2p1="http://www.w3.org/2001/XMLSchema" i:type="d2p1:string">Foo</Value>

   5: </ContextItem>

在上面的例子中，ContextItem的ReadOnly排在Value的前面，会先被序列化。那么，是不是我们要更新Value或者ReadOnly的数据成员（DataMember，不是属性名称）呢？这肯定不是我们想要的解决方案。在SOA的世界中，DataMember是契约的一部分，往往是不容许更改的。

如果在不更改数据成员名称的前提下让属性Value先于ReadOnly被序列化，需要用到DataContractSerializer另一条反序列化规则：我们可以通过DataMemberAttribute特性的Order属性控制序列化后的属性在XML元素列表中的位置。

为此，我们有了答案，我们只需要将ContextItem稍加改动就可以了。在如下的代码中，在为Value和ReadOnly两个属性应用DataMemberAttribute的时候，将Order属性分别设置成1和2，这样就能使ContextItem对象在被序列化的时候，Value和ReadOnly属性对应的XML元素将永远会有前后之分。这里还需要注意的是，在Value属性的Set方法中，判断是否只读，采用的不是ReadOnly属性，而是对应的readonly字段。这一点非常重要，如果调用ReadOnly属性将会迫使该属性被反序列化。

   1: [DataContract(Namespace = "http://www.artech.com")]

   2: public class ContextItem

   3: {

   4:     private object value = null;

   5:     private bool readOnly;

   6:     [DataMember]

   7:     public string Key { get; private set; }

8:

   9:     [DataMember(Order = 1)]

  10:     public object Value

  11:     {

  12:         get

  13:         {

  14:             return this.value;

  15:         }

  16:         set

  17:         {

  18:             if (this.readOnly)

  19:             {

  20:                 throw new InvalidOperationException("Cannot change the value of readonly context item.");

  21:             }

  22:             this.value = value;

  23:         }

  24:     }

  25:     [DataMember(Order =2)]

  26:     public bool ReadOnly

  27:     {

  28:         get

  29:         {

  30:             return readOnly;

  31:         }

  32:         set

  33:         {

  34:             readOnly = value;

  35:         }

  36:     }

  37:     //Others

  38: }

有兴趣的读者可以亲自试试看，如果我们进行了如上的更改，前面的程序就能正常运行了。到这里，有的读者可以要问了，你不是说仅仅有一行代码的变化吗，我看上面改动的不止一行嘛。没有错，我们完全可以作更少的更改来解决问题。

四、解决方案二：将数据成员定义在字段上而不是属性上

我们再换一种思维，之所以出现异常是在反序列化的时候调用Value属性的Set方法所致。如果在反序列化的时候不调用这个方法不就得了吗？那么，如何才能避免对Value属性的Set方法的调用呢?方法很简单，那就是将数据成员定义在字段上，而不是属性上。基于属性的数据成员在反序列化的时候不得不通过调用Set方法对数据项进行初始化，而基于字段的数据成员在反序列化的时候只需要直接对其复制就可以了。

基于这样的思路，我们对原来的ContextItem进行简单的改动——将DataMemberAttribute特性从Value属性移到value字段上。需要注意的，为了符合于原来的Schema，需要将DataMemberAttribute特性的Name属性设置成“Value”。

   1: [DataContract(Namespace = "http://www.artech.com")]

   2: public class ContextItem

   3: {

   4:     [DataMember]

   5:     public string Key { get; private set; }

6:

   7:     [DataMember(Name = "Value")]

   8:     private object value = null;

   9:     public object Value

  10:     {

  11:         get

  12:         {

  13:             return this.value;

  14:         }

  15:         set

  16:         {

  17:             if (this.ReadOnly)

  18:             {

  19:                 throw new InvalidOperationException("Cannot change the value of readonly context item.");

  20:             }

  21:             this.value = value;

  22:         }

  23:     }

  24:     [DataMember]

  25:     public bool ReadOnly { get; set; }

  26:      //Others

  27:     }

  28: }

总结

虽然这仅仅是一个很小的问题，解决的方案看起来也是如此的简单。但是，这并不意味着这是一个可以被忽视的问题，背后隐藏对DataMemberAttribute序列化的序列化规则的理解。

作者：Artech
出处：http://artech.cnblogs.com
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

一个关于解决序列化问题的编程技巧相关推荐

WCF技术剖析之三十：一个很有用的WCF调用编程技巧[下篇]
在<上篇>中,我通过使用Delegate的方式解决了服务调用过程中的异常处理以及对服务代理的关闭.对于<WCF技术剖析(卷1)>的读者,应该会知道在第7章中我通过类似于AOP的 ...
MATLAB cvx错误汇总，cvx错误解决，cvx知识点总结，cvx编程技巧
提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档文章目录前言 cvx编程错误及解决方法汇总错误1-无法从 cvx 转换为 double 错误2-等号问题错误3-{real af ...
有人说中文编辑是解决中国程序员编程效率的秘密武器，请问他是一个银弹吗？...
一."银弹" 首先在这里解释一下"银弹"的概念,顾名思义就是银质的子弹(Silver Bullet),是古老的欧洲民间传说中能杀死狼人的利器.当然现实中是没有狼 ...
你不知道的18个Python高效编程技巧
来源 | Python编程时光初识Python语言,觉得python满足了我上学时候对编程语言的所有要求.python语言的高效编程技巧让我们这些大学曾经苦逼学了四年c或者c++的人,兴奋的不行不行 ...
VC++ 常用编程技巧总结
VC++6.0的使用以及编程技巧整理 1.MDI子窗口一启动就最大化 BOOL CChildFrame::PreCreateWindow(CREATESTRUCT& cs) ...
python高效编程15个利器_你不知道的18个Python高效编程技巧
来源 | Python编程时光初识Python语言,觉得python满足了我上学时候对编程语言的所有要求.python语言的高效编程技巧让我们这些大学曾经苦逼学了四年c或者c++的人,兴奋的不行不行 ...
18 个 Python 高效编程技巧，Mark！
点击"小詹学Python",选择"置顶"公众号重磅干货,第一时间送达本文转载自Python数据科学,禁二次转载初识Python语言,觉得python满足了 ...
干货 | 18个 Python 高效编程技巧
点击上方"小白学视觉",选择加"星标"或"置顶" 重磅干货,第一时间送达初识Python语言,觉得python满足了我上学时候对编程语言的 ...
爱了，这18个 Python 高效编程技巧真香
初识Python语言,觉得python满足了我上学时候对编程语言的所有要求.python语言的高效编程技巧让我们这些大学曾经苦逼学了四年c或者c++的人,兴奋的不行不行的,终于解脱了.高级语言,如果做 ...

一个关于解决序列化问题的编程技巧

一、问题重现

二、问题分析

三、解决方案一：通过控制属性反序列化顺序

四、解决方案二：将数据成员定义在字段上而不是属性上

总结

一个关于解决序列化问题的编程技巧相关推荐

最新文章

热门文章