第三部分 ESFramework 使用技巧.docxVIP

第三部分 ESFramework 使用技巧/ESFramework_Serialize.aspxESFramework 使用技巧 －－ 使用紧凑的序列化器，数倍提升性能 在分布式通信系统中，网络传递的是二进制流，而内存中是我们基于对象模型构建的各种各样的对象，当我们需要将一个对象通过网络传递给另一个节点时，首先需要将其序列化为字节流，然后通过网络发送给目标节点，目标节点接收后，再反序列化为对象实例。在/ESFramework_00.aspxESFramework体系中，也是遵循同样的规则。 ESFramework称这些需要经过网络传递的对象称之为协议类（Contract），协议类通常只是一个简单的数据结构封装，用于保存状态的一个哑类（不包含任何业务方法，从object继承的除外），有点类似于与数据库中表进行映射的贫血Entity。基于ESFramework的分布式系统使用这些协议类实例进行数据交换。当我们使用Rapid引擎时，我们会经常使用ESPlus.Application.CustomizeInfo.Passive.ICustomizeOutter接口的Send等方法发送二进制自定义信息，这个二进制信息通常是系统中的某个业务对象的序列化结果，而这个序列化过程我们必须自己来实现。?一.序列化方式的两种选择 为了将业务对象转换为二进制流，大家通常有两种方案可以选择：使用.NET自带的二进制序列化器，或，先将业务对象转换为字符串（比如xml），再将结果用类似UTF8进行编码得到字节流。 这两种方案都有缺陷。1..NET自带的二进制序列化器 使用.NET自带的二进制序列化器对我们来说是最方便的，因为只要直接调用API就好了，不需要我们自己动手做任何动作。但是，缺陷也很明显：（1）强侵入性。 首先，能够序列化的类必须加上Serializable标签，且.NET自带的二进制序列化器需要绑定被序列化的类的命名空间和程序集。比方说，将windows里序列化一个协议对象得到的结果传到Silverlight中，是无法完成反序列化的，即使Silverlight中也有完全相同的协议类定义。这也说明，如果通信的客户端是用Silverlight开发的，肯定是不能使用.NET自带的二进制序列化器的。（2）序列化结果臃肿，其size巨大。 在巨大并发高性能的分布式通信系统中，这将降低通信消息，并浪费大量的带宽，是不可忍受的。（3）效率低下。 .NET自带的二进制序列化器基于反射（Relection）的机制工作，比如读取类型的信息、读取/设置字段的值等都是通过反射来完成的。如果每秒仅仅序列化百千个对象，可能还可以应付；但是如果每秒需要序列化几万、甚至几十万个对象，就不堪重负了。（4）加密困难。 由于.NET自带的二进制序列化器在序列化协议对象时，会反射读取对象的内部成员（private），而如果定义协议的dll经过加密后，private成员的名称通常会被混淆成随机的名称，这样就要求通信的各方都使用同一个加密的dll，否则，协议对象的反序列化可能会失败。?2.通过string进行中转 为了解决类似Silverlight客户端与服务端通信的序列化统一的问题，我们可以使用string作为中转，而无论是否为Silverlight环境，对同一字符串进行相同格式（如UTF8）的编码，得到的字节流肯定是一样的。反过来，同样的字节流在不同的环境中使用相同的解码器进行解码得到的字符串也一样。这是一种可行的方案，但是缺点也是有的：（1）我们需要自己打造协议对象与字符串之间的相互转换 -- 这可能是一个费时费神的又容易出错的工作。（2）序列化之后的结果的Size取决于我们协议对象与字符串之间相互转换时所采用的规则，同样也取决于我们的耐心程度 -- 为了使结果的Size更小，我们要动更多的脑筋。 当然，现在也有现成的将对象与字符串想换转换的工具，比如JSON和XML。就一般而言，使用JSON转换协议对象得到的结果比使用xml要小很多。（3）同.NET自带的二进制序列化器，对象属性值的读取/设置、对象的创建等通常也是基于反射的，所以，效率同样存在问题。?二.第三种方案 ESPlus提供了更紧凑、且不需绑定命名空间和程序集的二进制序列化器：ESPlus.Serialization.CompactPropertySerializer。（1）CompactPropertySerializer 基于Emit技术和缓存技术构建，且避免了反射带来的开销，所以效率大大提升。（2）CompactPropertySerializer 内部使用了简练、紧凑的序列化格式和规则，使得序列化的结果Size更短小。（3）将被序列化的类不需要增加任何标签，且不依赖于命名空间和程序集，只要类的定义完全一致，Com