2004年11月23日

  国产开源对象关系持久化框架DudoJ正式更名为OpenORM。经过了几个月的开发,终于发布了OpenORM的第一个版本,这个版本相比以前的版本在映射方面进一步增强,支持多种映射模式,添加更多功能,开发更方便。

2004年08月30日

今天发布了DudoJ框架的1.0.2b版,同时更新了开发参考手册。这个版本对映射部分代码作了一些简化,使以后代码更以维护。添加了关系测试代码,查询映射代码,存储过程测试代码。以前都是些的一些不规范的测试代码,这个版本加入了Junit的测试用例。计划以后每添加一项功能都针对这个功能编写一个测试用例,防止在修改某处代码是,出现新的Bug。没有时间编写示例代码,希望感兴趣的朋友能够通过这些测试代码,理解DudoJ的开发方法。

2004年08月15日

2004年8月16日,DudoJ数据持久化框架新版1.0.1b发布,同时发布了开发参考手册,这个版本比上一个版本在查询定义方面更加简化。

2004年08月09日

经过了10个多月的开发,终于可以发布第一个测试版了。官方网站http://www.dudoj.org

2004年08月02日

        经过了10个多月的开发,到现在总算可以推出第一版了。总算可以告一段落,当然后面的路还很长,还有更多的事情要做,在功能方面还有许多没有实现。好想有个志同道合的人能够一起来做,一个人做真是累啊。

2004年07月01日

  在DudoJ框架开发过程中,要对持久类映射进行缓存,理所当然的我使用HashMap来保存持久类映射,使用class作为键。然而看似简单的事情,在测试时却完全出乎我的想象。我的测试是使用DudoJ框架开发了一个小型的演示项目,这个项目是基于J2EE多层体系结构的,我将他发布到JBoss3.2.1(内置Tomcat)下。在第一此部署时没有任何问题,然而,当我重新部署(热部署)时,测试功能无法完成,检查原因,是没有生成正确的持久类映射。在DudoJ框架的内部,持久化持久对象之前,首先要在HashMap(缓存了持久类映射信息)中根据持久对象的类型(getClass()),得到持久类的映射信息,由于没有找到相应的持久类映射信息,没有生成正确的sql语句,所以测试功能无法完成。我感到非常困惑,为什么第一次部署没有问题,而第二次会找不到持久类映射。经过了反复的实验和尝试,验证了持久类映射部分(读取映射文件,生成持久类映射并以持久类为键放入HashMap中)是没有问题的。我初步怀疑是HashMap的键出了问题,我不用class做键,改用类名做键(class.getName()),经过反复的试验证明推断是正确的,改用类名做键以后,前面的问题不复存在。

  为什么用class做键,在JBoss中会出现这样的问题呢?在其他的容器中是否也会出现同样的问题?对于其他的服务器我不太熟悉,没有事件去验证了。到底是什么原因造成的呢?是否跟JBoss的类的加载机制有关?我不知道确切的答案。但是有已点可以肯定,使用以class为键的Map在容器中有可能造成键实效的问题

  后来,我在想,是否一个类在jvm中加载多次造成了class键在HashMap中实效。后来我检查了我的项目,发现我的持久类在我的Ejb模块和web模块中都被打包进去了。初步的实验证明,如果不部署web模块,只部署ejb模块,通过客户端调用EJB对象,而不通过web模块调用,无论多少次的热部署,都不会出现前面的问题。我想,在一个容器的项目中部署重复的类是造成class键在HashMap中实效的根本原因。我没有时间去做进一步的深究,希望有一天知道具体的答案。

2004年06月28日
  1. 使用java撰写SQL脚本能力
  2. SQL函数支持
  3. 强大的查询功能
    • 静态查询定义
    • 动态查询生成
    • 查询映射
  4. 存储过程支持
  5. 平滑的数据库平台移植
  6. 多数据库连接支持
  7. 简单易用的API
  8. 自定义对象(UDT)持久化能力
  9. 良好的批量数据处理性能
  10. 灵活的用户定制机制
  11. 开放源代码
  12. 支持类的继承,多态等特性
  13. 自动生成SQL脚本
  14. 更多……

  DudoJ是一个基于java的数据持久化框架,但它完全不同于其他的持久化框架,她给系统开发带来了许多令人振奋的功能。

  • 使用java撰写SQL脚本能力
      DudoJ 为您提供了使用java编写SQL脚本的能力。目前我们的应用数据绝大多数还是存储在关系数据库中,在应用中使用SQL语句来操作数据是我们最常用的方式。传统的方式是在编码时以硬编码方式在代码中嵌入SQL语句。这种方式带来的副作用是显而易见的。使用DudoJ做为企业应用的持久层,程序操作的都是java对象,一方面,将您的应用与数据库有效隔离,另一方面,在编译期就可检查对象、对象属性引用是否正确,而不象JDO一样要到运行时才能检查出错误。虽然不是什么重要的功能,但却能够提高我们的编码效率(同样的借助IDE的Code Insight 功能可以快速找到对象属性)。
  • SQL函数支持
      DudoJ 已经实现了常用的字符串函数、数学函数、日期函数,以后还会实现更多的函数。在DudoJ中使用函数,您不必担心不同数据库平台函数实现的差异,DudoJ为您提供了统一的函数接口,针对不同的数据库平台,DudoJ会自动的产生正确的映射。
  • 强大的查询功能
      借助DudoJ提供的函数功能和使用java撰写SQL脚本的能力,您可以使用DudoJ框架在您的应用中定义很复杂的查询。使用DudoJ您可以定义静态查询(在设计期将查询定义为一个类),也可以在运行时生成查询(动态查询),甚至允许您在映射文件中定义查询,实现任何复杂SQL的查询功能。
  • 平滑的数据库移植
      您是否经历过将您的应用从一个数据库平台转移到另一个数据库平台?是否为了不同数据库平台SQL实现的不同而不厌其烦的修改您的代码?相信许多人都经历过这些痛苦的时刻。现在,有了DudoJ数据持久化框架,您不必再为这些繁琐的事情所烦恼。使用DudoJ作为您应用的持久层,可以将您的应用毫无更改的移植到DudoJ支持的任何一个数据库平台,而不需要对程序代码做任何的更改。由于时间关系,也由于数据库平台的种类繁多,存在一些DudoJ目前不支持的数据库平台,但是DudoJ提供了灵活的扩展机制,在DudoJ的基础上您可以为您使用的数据库编写扩展模块,而这些模块是与应用无关的,您可以在您的不同应用之间重用这些模块。
  • 多数据库连接支持
      DudoJ不但支持多种数据库平台,而且支持多数据库平台协同工作。在DudoJ中通过设置配置文件,允许多个数据库平台同时工作在DudoJ框架中,数据库平台的数量没有限制。DudoJ甚至允许您在多个数据库平台之间建立数据关系,在进行对象的查、增、删改时,DudoJ会自动处理不同数据库连接的数据获取和更新。
  • 简单易用的API
      DudoJ框架对SQL函数提供了统一的接口,对不同的数据库的函数名进行了统一,您只需要了解DudoJ框架提供的函数定义即可,不需要了解低层不同数据库的差别,极大的简化您的开发工作。DudoJ也针对应用开发中碰到的一些问题进行了简化,比如分段查询,传统的在不同的数据库平台您需要别写不同的代码以适应在不同的数据库平台上进行的最优化的查询,使用DudoJ,您只需要使用Limit函数即可,您不需要担心不同的数据库平台上查询的效率问题,DudoJ会针对不同的数据库平台会自动生成有效率、正确的查询代码。
  • 自定义对象(UDT)持久化能力
      DudoJ框架提供了用户自定义对象持久化功能。您只需要为要持久化的对象实现SQLData接口,该对象就能够做为持久对象的一个属性值被持久化。对于Map,List,Collection,Set,您不必为这些对象实现SQLData接口(容器中的自定义对象需要实现SQLData接口),DudoJ会自动持久化这些对象。
  • 良好的批量数据处理性能
      为了实现通用的功能,各个框架产品都不可避免的要使用反射机制。通常的框架产品在操作对象数据时,对于每个对象的每个每个数据项都会使用反射来读取或者设置数据,而DudoJ采用了特殊的机制,只在对象初始化时使用反射,在以后的数据读取和设置时都不再使用反射,对于大批量的数据处理,这种机制能够在一定程度上提高系统效率。
  • 灵活的用户定制机制
      DudoJ拥有一个灵活的体系结构,允许您对DudoJ框架本身的功能进行扩展,而且DudoJ为您提供了扩展的切入点。通过扩展DudoJ框架,扩展DudoJ框架没有涉及到的方面,适应您以及您的客户多样化的需求。
  • 开放源代码
      DudoJ在GNU LGPL许可协议下发布,所有源代码公开。

  经过了这几个月的开发,心里对于整个框架的开发有了越来越清楚的认识,DudoJ持久化框架以后必将实现以下两个功能:

  1. 不止能够将数据持久化到关系数据库中,还可以将数据持久化到硬盘文件、网络流等其他的介质中。
  2. 采用DudoJ框架开发的企业应用,不需更改任何代码即可从一个数据库平台迁移到另一个数据库平台运行。

我将这两个目标称为DudoJ框架的“超级梦想”。其中的第一个在架构设计上已经预留了接口,第二个目前已经初步实现,所以这个“超级梦想”不久的将来将会变成现实。

  为了实现这个“超级梦想”在闲暇之余,无时无刻不在思考着如何简化设计,如何设计简单易用的API接口,总是试图寻找能够最大化简化应用设计的框架方案。在实现功能的同时又注重灵活性,尽量将框架设计成模块化的,各部分之间松耦合,尽量做到每个部分都是可替代的,可由用户定制的,使系统具有足够大的灵活性。

  如果您认为这个“超级梦想”不可能变成现实,那就请你拿起砖头砸我吧!^-^

2004年06月23日

  在我更进一步的开发工程中,我实现了多数据库集成,使得多个数据库可以在DudoJ框架中协同工作,只要我们在配置文件中指定持久类以及查询所在的数据库,在编码时不需要理会底层使用的是什么数据库、有几个数据库,我们只需要调用DudoJ框架的持久化接口,就可实现数据的持久化和恢复,极大的简化了编程工作。在完成了这些开发工作以后我又在想,如果用户底层更换了数据库,而应用程序如果不需要任何的更改,这岂不是可以极大的增强用户系统的适应性。接着我对整个框架进行了重构并增加SQL函数支持,并在mysql,sql server,db2,postgresql,oracle9i上进行了测试,并且全部测试通过。其实在实现此项功能之前,我并不能确定这个功能一定可以实现,因为我不知道不同的数据的差别有多大,毕竟我对于除sql server以外的其他数据库并不是很精通,在实现的初期确实遇到了一些比较棘手的问题,不过最终还是找到了解决办法。我的得到的经验是,任何一件事你不尝试实际动手去做,那么可能永远也不知道结果,只要你拿出实际行动努力的去做,那么哪怕最终是失败的,但你总是知道了结果,总比什么都不知道的好。

  如果说我初步的设想只是解决持久化数据的查询问题,那么第二步的设想我觉得是解决企业应用跨数据库平台运行的问题。如果说java使我们的系统能够Write once,run anywhere!那么Dudoj框架使企业应用实现Write once,run anywhere!只不过前者的run anywhere是指操作系统,而后者的run anywhere不单指操作系统平台,还指数据库平台。毕竟绝大多数的企业应用都是与数据库相关的。要让企业系统实现跨数据库平台应用,一般的,程序员必须写出许多针对性的代码,更换一种数据库,就必须更改代码,这给系统维护带来了很大打麻烦。使用DudoJ数据持久化框架开发企业应用,让企业应用真正的实现Write once,run anywhere!这也是我的设想,更试我的梦想,我会一直向这方面努力,并且现在也有了一定的实现基础。