一、序列化组件与数据库访问组件的对比
| 序列化组件 | 数据库组件 | 说明 |
|---|---|---|
| IDL | DDL | 用于建表或者模型的语言 |
| DL file | DB Schema | 表创建文件或模型文件 |
| Stub/Skeleton lib | O/R mapping | 将class和Table或者数据模型进行映射 |
二、JSON（Javascript Object Notation）
JSON起源于弱类型语言Javascript， 它的产生来自于一种称之为"Associative array"的概念，其本质是就是采用"Attribute－value"的方式来描述对象。
实际上在Javascript和PHP等弱类型语言中，类的描述方式就是Associative array。JSON的如下优点，使得它快速成为最广泛使用的序列化协议之一：
（1）、这种Associative array格式非常符合工程师对对象的理解。
（2）、它保持了XML的人眼可读（Human-readable）的优点。
（3）、相对于XML而言，序列化后的数据更加简洁。 来自于的以下链接的研究表明：XML所产生序列化之后文件的大小接近JSON的两倍。
（4）、它具备Javascript的先天性支持，所以被广泛应用于Web browser的应用常景中，是Ajax的事实标准协议。
（5）、与XML相比，其协议比较简单，解析速度比较快。
（6）、松散的Associative array使得其具有良好的可扩展性和兼容性。
IDL悖论
JSON实在是太简单了，或者说太像各种语言里面的类了，所以采用JSON进行序列化不需要IDL。这实在是太神奇了，存在一种天然的序列化协议，自身
就实现了跨语言和跨平台。然而事实没有那么神奇，之所以产生这种假象，来自于两个原因：
（1）Associative array在弱类型语言里面就是类的概念，在PHP和Javascript里面Associative array就是其class的实际实现方式，所以在这些弱类型语言
里面，JSON得到了非常良好的支持。
（2）IDL的目的是撰写IDL文件，而IDL文件被IDL Compiler编译后能够产生一些代码（Stub/Skeleton），而这些代码是真正负责相应的序列化和反序列化
工作的组件。 但是由于Associative array和一般语言里面的class太像了，他们之间形成了一一对应关系，这就使得我们可以采用一套标准的代码进行相应的
转化。对于自身支持Associative array的弱类型语言，语言自身就具备操作JSON序列化后的数据的能力；对于Java这强类型语言，可以采用反射的方式统
一解决，例如Google提供的Gson。
典型应用场景和非应用场景
JSON在很多应用场景中可以替代XML，更简洁并且解析速度更快。典型应用场景包括：
（1）公司之间传输数据量相对小，实时性要求相对低（例如秒级别）的服务。
（2）基于Web browser的Ajax请求。
（3）由于JSON具有非常强的前后兼容性，对于接口经常发生变化，并对可调式性要求高的场景，例如Mobile app与服务端的通讯。
（4）由于JSON的典型应用场景是JSON＋HTTP，适合跨防火墙访问。
总的来说，采用JSON进行序列化的额外空间开销比较大，对于大数据量服务或持久化，这意味着巨大的内存和磁盘开销，这种场景不适合。
（1）没有统一可用的IDL降低了对参与方的约束，实际操作中往往只能采用文档方式来进行约定，这可能会给调试带来一些不便，延长开发周期。
（2）由于JSON在一些语言中的序列化和反序列化需要采用反射机制，所以在性能要求为ms级别，不建议使用。
出处：