网上关于JDO的文章已经不少了，关于JDO的优点也讲了很多，我看了一些文章后，自己也研究了一段时间，忽然很想写一个系列文章全面的介绍一下JDO，今天先写下第一篇算是个开头。呵呵，有些内容是我对JDO规范的理解，如果有不对的地方请大家指正。
Java开发人员已经有好几种存取数据库的方法：序列化，JDBC，面向对象映射工具，对象数据库，以及实体EJB。那为什么还要介绍其他的存储架构呢？答案是，上面每一种实现存储的方案都存在一定的限制。JDO正在尝试解决这些限制。
序列化 是Java建立的一种传输机制，它能够把对象的信息转换成一系列的字节码，这些字节码可以可以被传输到网络或者存储到一个文件中。序列化的使用非常简单，但他还是有限制的。它必须立即存取对象的特征，而且它不适合存取大批量的数据。在它更改一个对象的属性时如果有错误发生他不能回滚错误的修改，因此不适于应用程序的数据完整性要求。多个线程或程序不能同时互不干扰的读写序列化数据。所有这些不足是的序列化无法满足大多数数据存储要求。
许多程序员使用 JDBC
API来操作关系数据库。JDBC克服了许多序列化中存在的缺点：它可以操作大批量的数据，有确保数据一致性的机制，支持信息的并发存取，可以使用已经非常成熟的SQL语言。不幸的是，JDBC使用起来并不像序列化那么简单。JDBC使用的关系范例不是被设计用于存储对象的，因此，它迫使你放弃代码中使用面向对象程序存储数据的可能。
由软件厂商创建的架构可以为你实现对象和关系数据库之间的映射。 这种对象-关系映射支持可以是的你专注于对象模型的设计而不必关心面向对象和关系数据库之间的匹配。不幸的是每一种对象-关系映射支持都有一套他自己厂商实现的API。你不得不使自己的代码迁就某一个单独厂商的实现。假如这个厂商提高价格或者停止对bug更改的支持，如果你想用其他的厂商实现架构时，你就不得不重写你的代码。
比对象关系数据库映射更好的是，一些软件厂商开发了一种新的存储对象到数据库的方法。这种对象数据库使用起来常常比对象关系映射软件简单。ODMG组织成立的目的就是创建一个访问对象数据库的标准API。一些厂商也尊崇ODMG组织的要求，因此由于厂商实现不同带来的麻烦也解决了。一些公司对于从关系数据库转向对象数据库显得犹豫不决，因为有大量的数据存储在传统的关系数据库中。个别数据库分析工具可以用于对象数据库，然而大量的数据存储使用的仍然是关系数据库。由于这些原因，对象数据库被很好的利用。
Java平台的企业级应用中引入了实体EJB。 实体EJB是一个组件，他描述了数据库中的持久性数据信息。EJB使用类似于“对象-关系”映射的办法，它提供了一个持久性数据的面向对象的表示。不同于对象关系软件，EJB对于关系数据库没有限制；它描述的持久性信息可以来自一个企业信息系统（EIS）或者其他的存储设备。而且，EJB使用了一个严格标准，实现它的厂商必须遵循这个标准。不幸的是，EJB标准在面向对象方面稍微有些欠缺，比如一些高级的特性：继承、多态和复合关系等。另外，EJB的代码编写很复杂，而且它是一个重量级组建需要消耗应用服务器很很多的资源来运行。但是，EJB中的会话Bean和消息驱动Bean有很多优势，所以JDO规范详细定义了JDO如何与他们进行集成。
JDO集成了很多上述持久性机制的特性，这使得在JDO中创建一个持久类就像创建一个序列化类一样简单。JDO还支持批量数据的存储，数据一致性，并发处理和JDBC的查询功能。就像“对象-关系”映射软件和对象数据库一样，它允许使用面向对象的高级概念，比如“继承”。它避免了像EJB中实体Bean一样必须依赖于来自厂商定义的严格规范的限制。像EJB一样，JDO也不限定任何特定的后端数据库。
但是，这里还是要说一下，世界上从来就没有“万灵丹”。所以，JDO并不是对于每一个应用程序都是有好处的。很多应用程序完全可以使用其他更理想的存储机制。
