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

dlee，这里牵涉到一个混用多种范型的问题吧？

同时使用多种范型固然能获得更大的灵活性，但也容易同时获得多种范型的缺陷－－C++就是一个例子了

》只要大的界面（从外面看上去）是 OO 的就可以了。
对阿，可如何做到可真不简单啊
如果手工来mapping属性的话，那还是比较简单，就是繁琐了点

呵呵，我们的框架其实不是 OO 的框架。很落后是吧？要是在 Jdon，banq 先生肯定会出来说：你又在宣传一些落后愚昧、不合标准的东西！
一些具体的细节我不便透露，但是比你想象的要强大得多。
这些很容易发展成主义之争的，还是多研究些业务吧。我看大家对于谈技术很起劲，但是没有多少人真正在谈业务问题。

dlee， 技术总是不业务要好讨论一点的， 业务个人做的都不一样。 讨论的结果就是一个人说， 其他人听。
^_^

说的也是，确实是这个理。我们这里不是只能谈 OO  的，其它的技术只要 Java 能实现的都可以自由讨论。
解决技术问题的框架想要增值是一定要向业务框架的方向发展的。
只解决技术问题的框架是无法支撑起一个商业帝国的，IBM 卖钱的框架可都是业务框架。
OLAP 就是我们将来的方向。两个三月后等我有较深的理解后可以好好谈谈。

我一直不太明白dlee讲的业务问题、业务框架是在指什么，是具体应用的业务逻辑吗？大家搞的应用千差万别，涉及各行各业，怎么可能在这里谈呢？

为什么不能在这里谈呢？办公自动化你做过吗？物流你做过吗？财务你做过吗？某个领域有共性的东西都是可以谈的。我们这个论坛不是普通的技术论坛，就是要向高端的方向发展的。我们讨论问题的深度和广度都要超越其它的论坛。
业务、需求、建模，这些问题不关心你还想赚到钱吗？企业级框架所要解决的问题不仅仅是一个 ORM 这么简单。

我的这种思路在构造查询时确实没有jdo,或者hibernate看起来简洁，性能我没有做过对比测试，不过对于从设计上讲要比hibernate要高（不考虑cache，因为目前还没有实现cache）,因为我取数据时不用每增加一条记录就创建一个对象，而且不使用反射。

dlee说的没有错，不过这应该是两个问题，1是要不要成为业务专家的问题，2是在讨论区里面如何讨论业务的问题，是吧？就是因为没做过的行业太多，才会很难找到可以一起讨论具体领域问题的人，而且，业务问题还是和客户交流更有价值一些。倘若我开个主题：“通过银行缴税的纳税人如果逾期申报而且税款逾期到帐应该加收一次滞纳金还是加收两次滞纳金”，你估计一下会有几个人回复呢？而且，一旦上升到了业务框架的层次，恐怕同行之间更多的是猜疑、保守，生怕对方把自己的东西学了去吧！

回到第1个问题，不瞒你说，我现在正在做的项目涉及到了工作流，也有财务的部分，三个里面占了两个，也算不错了吧？我做过的系统涉及教育、商业、政府、运输等行业，但是你如果和我谈论这些行业的深层问题，我一定无言以对，因为以前并没有意识到要把业务学到手，眼里只有技术，但是不知道从哪一天开始，我意识到，只有把业务握在自己的手中，才能够做出好的产品，千万不要过分依赖于不太了解技术的业务专家，对技术、业务都很精通的人是一个成功项目的坚实后盾。我想在这方面我和dlee的观点是相同的。

离楼主的主题越来越远了，罪过罪过！

楼主的勇气可嘉，应该鼓励，尤其是任何与众不同的想法。
不过，O/R MAPPING框架确实是个很复杂的东西，我相信你有很多很多问题都没有考虑到，建议你去读一读前人的分析成果，说不定会对你有些帮助，这就有一篇：http://www.ambysoft.com/persistenceLayer.html

我的原则是，只要有现成的东西就直接拿来用，我一定不会去非要自己做一个来压住别人，除非这个东西缺陷太多让人忍无可忍。
你也可以看看这个。

非常感谢 Sybase EAServer！
   其实我只是一种尝试，将自己的想法实现出来而已，不求别人都认同我的想法。这个世界没有尝试就不会有发展，其实我写这个框架的动力也是来自于hibernate,当初我的同事在用它，告诉我那是一个业余爱好者写的，我以前以为象这些大的框架可能都是大公司来做的，没想的一个业余爱好者也可以写出这样的东西，而我为什么就不能呢。