一. 序列化与反序列的作用
为什么要有序列化呢，考虑下面这种情况，在WINFORM或者更为方便的WPF工程中，当我们进行UI设计时,可以随意的将一个控件剪切/张贴到另外一个地方。操作方便的背后是什么在发挥作用呢。控件明明是一个复杂的对象，却可以进行剪切张贴。这其中就涉及到了对象的转换。将控件这个复杂的对象转换为字节流，进行复制，然后再将字节流反转为控件对象。这样就实现了控件的随意剪切与张贴。
上述就体现了序列化的应用场合，数据传送。
定义：
序列化：将对象转换为字节流。
反序列化：将字节流转换为对象。
二.使用序列化
格式化器BinaryFormmatter(System.Runtime.Serialization.Formatters.Binary命名空间）
1. 序列化
BinaryFormatter.Serialize(Stream,object) 将需要转换的类型传入(object)，以及Stream引用 。然后就会得到stream对象
2.反序列化
BinaryFormatter.DeSerialize(Stream stream)传入stream引用，返回对象。
简单的demo:
三.设计类可序列化，控制类的成员可序列化
1.类可序列化：
类默认是不可序列化的，但是我们在设计一个类时通常需要将其设计为可序列化，方便后续使用。使类可序列化的方法很简单，引入Attribute。在类前面加上[Serializable](是System命名空间，而不是System.Runtime.Serialization命名空间)。这样类就可序列化了。因为设置类可序列化后，默认类中的所有字段都是可序列化的。而不论其是private，protected。这样对于一些需要保护的字段就极其不利了。所以接下来就是控制类的成员可序列化。
2.控制类的成员可序列化
类型中有些字段是不希望其序列化
- 反序列化后没有意义。比如Windows内核（文件，进程，线程等）这些与进程有关，反序列化后不是同一进程，得到的信息没有意义。而序列化的目的是在于将对象转化为字节流，最终还是需要进行反序列化得到原有结果的。
- 字段可以通过简单计算得到。这样的字段没必要进行序列化。序列化反而会增加传送的数据量。
那么如何控制字段不可序列化呢
- 字段前加上[NonSerialized]即可。但是问题来了，这样我们反序列化就得不到这个字段的原有值了。像上面所述的【能够通过简单计算】得到的字段我们不希望他序列化，但设置了[NonSerialized]，这样反序列后得不到想要的值。这样显然也不是我们希望看到的。解决办法就是使用[OnDeserialized]特性
- OnDeseriablized(StreamContext context)方法中重新计算标记为未序列化字段，因为有OnDeserialized特性，这样序列格式化器就会识别这个特性，对这个方法进行调用。类似的特性还有OnDeserializing,OnSerializing,OnSerialized。分别在序列化和反序列的不同时期调用。可以根据实际情况来添加对应的方法。看似已经解决了控制类的成员可序列化的问题了。但是又有一个新的问题。如果我现在在类型里添加新的字段。序列化格式化器处于性能的考虑，不会在一开始进行了字段是否可序列化的检查。而是调用时看是否能够序列化。序列化一个对象图时，只要有一个对象不能序列化【注意不是不可序列化】就会报异常。那么如果我们序列化一个类型的实例，在类型中添加新字段，然后反序列化不包含新字段的对象。那肯定会报错
- 解决2最后的问题，就可以通过OptionalFieldAttribute特性。这样格式化器就会识别这个特性，不会因为流中不包含这个字段而报错
四. 格式化器如何工作
无论是序列化，还是反序列化，还是识别特性OnSerialized等，都是格式化器在起作用。那么格式化是如何进行序列化与反序列化呢
序列化：
- 格式化器调用FormatterServices的GetSerializableMembers()方法，获取到需要序列化的字段
- 格式化器根据1取得的序列化字段调用FormatterServices的GetObjectData取得字段的对应值
- 格式化将程序集标示和类型名写入流中。
- 将1，2，取得的序列化字段和值写入流中。
反序列化：
- 读取程序集和类型名称，加载程序集
- 为对象分配内存。调用FormatterServices的Get'UninitzlizedObject（）
- 初始化字段
- 初始化字段对应的值
- 将分配的对象，字段，字段对应值引用传递给FormatterServices的PopulateObjectMembers（）方法