如何用JDO开发数据库应用（11）
· 5.2. 速度会不会慢？－－性能测试数据参考
我使用过一个有一定规模的应用来测试过JDO的性能，这个应用具有十多个类，每个类有5～20个属性，类之间有错综复杂的关系，功能很多，是一个完整的基于浏览器的Web应用。使用原始的自己的JDBC包装时，数据库相关的处理代码非常多，有10多K，而改造JDO后，这些代码都没了，实际上，相当于这些代码变成了JDO厂商的支持包。
接着是性能测试，原来的基于JDBC的应用每秒可处理8个请求，而采用JDOGenie作底层的JDO应用每秒可处理35个请求，采用KodoJDO作底层的JDO应用（手写的Java代码与JDOGenie一样）时，每秒可处理25个请求。这一切都归功于JDO规范所规定的延迟读取机制（Lazy Loading Mechanism）。
可能有眼尖的读者会问：为什么文章开头说Kodo是性能王者，而这里却不如JDOGenie呢？不错，眼睛实在是雪亮！这样的材质，怎么不去做私家侦察啊！搞个什么X美凤的片子，肯定一炮走红！
哦，对了，我还没给出解释。我前面说Kodo性能最好，是包括对稳定性的评价在内的。我这里对两者的测试，都是采用了JDO规范定义的乐观事务方式（javax.jdo.option.OptimisticTransaction），这种方式将事务的锁定限制在应用端，不对数据库造成压力，只是在对同一对象的并发改动很多的时候会导致很多冲突。一般来说，你的Web应用不会一天访问量上百万吧？假如不到，就完全可以采用这种事务处理方式。Kodo的事务处理在测试中成功机会比JDOGenie大很多，同样的测试时间，Kodo的类似访问数的统计数据比JDOGenie要多，也就是说Kodo的成功事务比JDOGenie多，尽管总访问数少于JDOGenie。综上所述，Kodo的性能还是要比JDOGenie好。不过JDOGenie也在奋起直追，我对它比较看好！
· 5.3. JDO1.0的局限性
好了，兴奋过后，应该是冷静的反思。
有一句话说得好，最值得相信的人，只有你自己！
我是一名JDO的狂热追随者，为推广JDO做着不懈的努力，当然免不了某些时候言语过激或片面化，所谓“一叶障目，不见泰山”。就象Java追随者认为.NET一无是处一样，实际上.NET有很多优点是Java无法相比的，比如快速，灵活。
我也冷静下来，仔细地思考了JDO1.0的不足之处，竟发现有很多：
增加额外步骤，配置复杂（相对于直接的JDBC）
对数据模型有一定限制（必须有一个无参构造器，属性访问需要getter和setter）
双向对象关系的处理太欠缺（JDO2.0计划中的自动维护的对象关系将解决这些）
JDOQL的API稍显累赘（declare一大堆东西，比ODMG的OQL标准还是不如）
没有数据库统计功能（count(),max(),avg()等等，不过已经在JDO2.0计划中）
5.4. JDO2.0展望
Sun的动作就是慢，象一个迟暮的巨人。JDO1.0讨论了四年才半推半就地现身，JDO2.0又还未正式立项，真不知何年何月才能真正解决数据库应用中的所有问题！不过群众的参与就是推动力，让我们一起提出我们的意见，一起推动JDO2.0的车轮吧！（我们可以对JDO规范制定人的邮箱狂轰滥炸，直到他们说“马上开始制定”或者“算了，给你十万$，饶了我吧”为止）。
6. 参考文章（中文）
实际上下面列出的文章基本上都可以直接在www.CSDN.net上通过搜索要害字“JDO”的技术文档来找到。
《JDO对开发的帮助有哪些》
《JDO能给我们带来什么》
《JDO资源介绍》
《一个JDO的成功案例分析》
《一个纽约女技术员的JDO经验》
《最权威的JDO新书》
《Java Data Objects第一章翻译》
《选择CMP还是JDO》
还可以在CSDN上找到一些其它作者写的文章。
7. 参考资料
JDO规范的主页－－JSR12， http://jcp.org/en/jsr/detail?id=012 ;
Sun网站中作为J2SE optional pack的网页－－ http://java.sun.com/prodUCts/jdo/ ;
核心推广网站－－ http://www.jdocentral.com ;
最集中的讨论区－－ http://www.jdocentral.com/forums/index.PHP ;
相关中文资源网之一－－ http://www.CSDN.net ;
相关中文资源网之二－－ http://www.JavaResearch.org ;
Versant的一份介绍材料： http://www.jdocentral.com/pdf/JavaDataObjects_McCammon.pdf ;
综合资料： http://www.jdocentral.com/JDO_Resources_Body.Html ;
