本文将介绍如何使用Sun公司的最新《Java Data Objects 》规范来进行基于数据库的简单应用程序的开发，从而使读者对JDO有一个直接的感性的认识，为更深入的开发作铺垫，同时也希望抛砖引玉，让更多的富有经验的高手也参与到推广JDO的进程中来，为读者提供更多更精彩的文章！
· 1. JDO是何方神圣，难道是ADO的翻版？
本节对稍熟悉JDO一点的读者来说，可能算是老生常谈，一堆垃圾，不如回收掉算了。不过我却认为这些是实话实说，有感而发，不吐不快，对新手可能也有一定的帮助，至少应该有一点共鸣吧。所以，老手请直接跳过本节。
· 1.1. Java的优点
自从Java语言面世以来，它那几乎完全面向对象的特性和解放我们程序员的自动垃圾回收机制给我们展现了一个全新的开发天地：原来程序还可以这样写！我用过几年C++，里面的指针简直折寿！我还记得有些功能里面不得不使用类似“***lpszInfoMapOfMap”之类的变量，它是指针的指针的指针，要在编码过程中准确地把握这一点已属不易，何况还要记得释放每一处占用的内存，并且还不能释放多次（严格地说，应该是将自己申请的内存进行且只进行一次释放）！
我至今都还很佩服当年清晰的头脑，然而在调试过程层出不穷的“AccessViolation”和“NullPointer”错误竟使我一夜白头！（有一次熬夜调试一个问题，第二天憔悴了很多。）C++之后，我也用过三年以上的Delphi，程序代码好理解、易维护了很多，不过指针仍是胸中永远的痛！直到Java，才使我脱离苦海，进入“按思维的速度进行开发”的时代……
当Java的速度得到很大改善后，我们开始用它来写数据库应用，但说实话，Java的数据库方面还很原始，图形界面编程中的数据库组件很不好用，再加上主要写的是Web应用，只有JDBC接口可供选择。提起JDBC，我相信很多读者都会有这样的印象：概念太多，严密但麻烦，尤其是资源的释放也是一大问题。比起微软的ADO来，简直是一团乱麻，容错性尤其差劲。
· 1.2. 对象包装技术，百家争鸣？群魔乱舞？
于是，从规范化开发的原则出发，我们开始写自己的JavaBean来包装数据对象，使数据对象化，避免太多的地方涉及JDBC操作。但一些问题也随之而来：灵活性不够，接口死板，性能低下，这使我一阵苦恼。于是，“君子性非异也，善假于物也”，咱也上网去找点“技术支持”！很快，竟然被我发现了“Castor JDO”，一个专用于数据包装的撞阕榧峁┝薕DMG标准的OQL作为查询语言，方便且容易理解，比SQL好多了。这让我享受了一段时间的“面向对象的数据库开发”的好处，一句话，“效果不错，还实惠！”。
然而，好景不长，Castor一些内在的BUG影响了稳定性，而这个免费产品的更新又太慢，一直未能解决。只好放弃。“执手相看泪眼，竟无语凝噎”！怎么办？要知道，由俭入奢易，由奢入俭难，吃过肉的人，怎能忍受只能吃菜的生活！象《甲方乙方》里面那个一心想吃素的大款还是不多见的。对我们来说，再使用JDBC原始调用似乎难以下咽，再用JavaBean包装又有点返古，于是我又开始了网上的搜寻历程。余秋雨先生有《文化苦旅》，咱这也算是《编程苦旅》了，呵呵，苦笑。
从网上的资料来看，我的这些经历也是很多Java开发同仁的共同经历，无论是国内还是国外，不过从实际情况来看，国外的研究更深入更广泛一些，至少从网上所能找到的资料来说是这样。美国从八十年代起就开始研究面向对象的数据库ODBMS，目前已有一些成形的产品，比如Versant公司的Versant数据库，FastObjects公司的FastObjects t7数据库，以及其它一些相对市场份额小一些的诸如ObjectStore等公司的产品，当然，也不乏一些免费的产品，如Orient等等。总的来说，ODBMS尽管拥有面向对象的优点，但由于历史原因，在与关系数据库RDBMS的竞争中始终处于下风，基于RDBMS的应用还是占绝大多数，因此，出现了Object-Relational映射的一些工具，前面提到的Castor就是近年来出现的一个工具，实际上更早的时候，已经有一些成熟、稳定的商业化产品出现，比如前一阵被Oracle收购的TopLink，被BEA收购的WebGain等等，比较有名气的CocoBase等等。
象TopLink这样的产品我也了解了一下，功能确实强大，性能、稳定性都有优势，然而，其同样强大的价格和古怪的API令我却步。我很担心被锁定在某个产品上面，无法脱身，众所周知，Java给我们的就是一种自由的感觉，自由，永远是那么地吸引人。
出路在哪里？JDO浮现在我眼前。
（未完待续）
文章来源于领测软件测试网 https://www.ltesting.net/
