如果有一个新的数据持久化框架，您希望他能帮你解...

我猜这个论坛上恐怕不会有人同意Gavin只是个“业余爱好者”吧？

我同事说的，我可还真不了解，不过“业余爱好者”是指他没有工作。~_~

好久没有来了^_^

楼主的举动很好.
其实如果要做自己的ORM可以在HB的基础上进行修改(或者扩展).
什么批量update或者其它的,是因为HB要考虑cache等问题(在它的网站上也有说,本论坛也有),如果只考虑自己目前的项目或者特殊的个人需要,你完成可以在它的基础上实现批量update等功能.
关于面向OO的查询,HB已经做得很不错了,楼主你说的那种查询在HB上也有(robbin前面说过).
当然重构这的确是一个问题,但一般我们都会把那些SQL操作封装在某个类上,所以要修改也是比较简单的,要不你就用 sql.append("..").(类名.class.getName())等方法或者HB那个OO查询罗.
关于配置文件,其实HB没有想象的那么复杂(如果是用了CMP,就知道),再说现在有那个xdoclet容易多了,根本就不用写什么配置文件,而且还可以直接生成SQL.表都不用建啦.

关于楼主那个自定义类型,在HB中也有,但那些基本类型是不需要再定义了(全世界都希望是这样),如果只用某种ORM的api的话,移植性就完了(现在HB也很关心这个问题),再说你那种什么FieldString,如果转换其它到String还要再转一下呢(麻烦呀).

当然HB不是万金油.

虽然说了这么多,我还是支持楼主的,因为动机和精神很可贵.
努力吧.
祝你成功.

使用sql builder之类的办法会导致很多程序员觉得麻烦最后还是直接写sql算了...

　　没想到这个贴子过了这么久还有人关注。
　　大概是去年10月份吧，也不知道在某一刻，我突然在想，为什么我不能用对象直接构造SQL语句而要用字符串呢？没有人做、没人想到还是有什么困难不能克服呢？就这样，经过了一番思考终于有了初步的想法（初步的想法：将持久对象继承自我定义好的持久类，属性定义为我设计好的类，而不是java中已有的类，通过给这些我定义的类添加方法和函数，这样他们就可以按照我的想法进行操作），管他呢，先写一些代码试试。通过测试方案是可行的，于是我有了继续写下去的决心。
　　我知道到我不是一个java高手，更进一步的开发会遇到更多更复杂的问题，但是我自认为我特别善于学习，而且现在有网络，可以找到很多我需要的资料。在后续的开发中，确实遇到了很多的问题，我现在才真正觉得网络是一个很好的工具，特别是google,他真是一个百科全书，记得又一次我把程序的出错信息整个的拷贝下来放到google中搜索，他竟然搜索到了我的问题的答案。希望象我一样的低手们要好好利用网络，因为他就在你的身边，有了疑问先去在网络上搜索答案，而不是先去向别人提问，而且在你搜索的过程中，你还会了解许多相关的知识，如果你向别人提问，相信他只会告诉你问题的答案或者什么也没有，不会告诉你更多，因为他可能很忙。
　　也不知道经过了多少个日日夜夜（其实还不到360个，不过大家都是么说的~-~），经过了多少次重构，终于在3月份的时候有了第一个可用的版本，本想发布出去公开测试，但是却又觉得很多地方还是实现的不好，再改！很多时候我觉得要实现一个功能很简单，但是要很好的实现一个功能却十分的困难，因为，一个功能不单是实现的问题，还有使用的问题，实现只是功能完成既定任务的问题，而使用却存在用户接口的问题，要让用户直观方便的使用这个功能，就需要站在用户的角度去反复的实验。有时候为了一个函数名称都的要认真思考老半天。
　　我是一个追求完美的人，我总希望这个框架能够实现目前我既定的功能，我更希望她能够经过深入完善的测试，在推出时可以比较稳定的工作，我也在这方面做了一些努力，写了一些测试代码。我也希望写许多的示例代码和使用文档，帮助喜欢她的人更快速的了解并掌握他，但是一个人的精力和时间是有限的。在这个现实的社会里，我必须抽出大量的时间来为生计而奔波，还要抽出一定的时间来陪家人。所以如果你以后在使用dudoJ框架时遇到什么问题请你不要埋怨我，我已经尽力了。或者你跟本就对她不感兴趣，那么也不要紧，对您来说也没有什么大的损失。这个框架不一定适合你用，也不一定就有人用。有人会问，你是个白痴吧，每人用的东西写出来做什么。问的好，也骂的好，我可能是有点神经质，我也不知道为什么要花这么多的精力去做，但是我只有一点可以肯定，那就是我在实现我的思想，而且这一次是完全的按照自己的意愿去实现，而不是别人的。不管你同意不同意，你在公司做的所有的东西都是在实现别人的思想，哪怕整个项目是你一个人完成的。
　　很快我要接手一个新的项目（公司的），要两到三个月吧，可能要在公司加班，所以这段时间会很少有时间花在这个框架上面，但是我也不希望这个框架一直就这样拖下去不发布，所以我想尽快完成目前的更新部分，也算是告一段落，可能没有时间进行更深入的测试，欢迎感兴趣的朋友进行测试并提出改进意见。不过我可以保证这个框架已经经历了一个小型项目的检验，而且系统运行稳定。

　　目前更新的是两个部分，一个是关系处理部分，以前实现的感觉不是很好，正在重写。另一个是事务处理部分，准备集成jotm事务管理框架，以支持jdbc跨数据库事务处理能力。

　　当然欢迎有兴趣的朋友就持久化关系处理和跨数据库事务处理这两个主题展开讨论，提出你的想法和意见，当然更欢迎有兴趣的朋友加入一起来做。

实在没有时间在花在网站上，所以只有首页，首页说明了DudoJ框架目前具有的一些特点。

  http://www.dudoj.org

ORMapping有必要搞的那么复杂吗?

我的方案比较傻瓜。

Entity entity = new Entity("客户资料", "CustomerInfo);
entity.AddColumn("帐号", "ID", "varchar");
entity.AddColumn("姓名", "Name", "varchar");
entity.AddColumn("性别", "Sex", "varchar");
entity.AddColumn("生日", "Name", "datetime");
entity.AddPK("帐号");

Data customer = new Data("客户资料");
customer.AddData("帐号");
customer.AddData("姓名");
customer.AddData("性别");
customer.AddData("生日");

customer.SetData("帐号", "1060");
customer.SetData("姓名", "张三");
customer.SetData("性别", "男");
customer.SetData("生日", "2000-1-1");

ORMapping orm = new ORMapping(entity, customer);
orm.Insert();

Data newdata = customer.Clone();
newdata.SetData("姓名", "李四");
orm.Update(customer, newdata);

hi age0，你的OR mapping方式和OFBiz的entity engine非常相似，是一种灵活的基于generic map的解决方式。
Hibernate 3.0里面有准备提供这种方式的支持。

但是我开始逐渐喜欢写胖胖的domain object，而不是像这种纯data的数据结构object。这种data object的缺点在于难以复用（纯数据，java的多态，扩展，以及一些设计模式比较难用得上），重构（没有ide支持，比如改名）和测试（比如名字写错无编译期间提示）。不知道你在实际项目中是怎么解决这些问题的？

怎么说好呢，我的整体设计概念是完全反传统的，对象的继承基本上是禁止的，对象之间只通过组合方式进行交互，所以不存在多态、扩展或设计模式之类的问题。

重构基本上只能由自己来做，不过因为系统对象数目不多，所以工作量不算太大，况且重构时经常要调整对象之间的协作关系，以更合理的方式重新划分职责，这些工作单靠工具是无法完成的。

测试确实是个大问题，因为在编译时无法进行，所以只能根据它们之间的依赖关系在运行时的部署阶段进行检查。
例如：
Entity entity = new Entity("客户资料", "CustomerInfo);
entity.AddColumn("帐号", "ID", "varchar");

Data customer = new Data("客户资料");
customer.entity = entity;

customer.AddData("帐号");     // 如entity没有"帐号"则返回错误提示

事实上，Data 和 Entity 之间的关系是非常松散的，只有当两者拥有相同名字的元素时才会发生关联。为此，Data甚至增加了AddVirtualData()的方法，Data同样可以通过AddEntity()的方式增加多个关联实体，关键是ORMapping有能力自行处理多个实体之间的复杂关系。