反思Hibernate，可以有更简洁、更高效的ORM实现

这个问题实际是由某位大牛引发的“贫血模型”之争。在hibernate出现之前，很多公司其实已经有了自己的持久层框架，像楼主提到的方案，有不少公司在用。ufida的持久层方案介于本讨论和hibernate之间的，由dao负责对pojo进行存取，但是没有映射文件，通过反射实现映射的

个人认为hibernate真正伟大之处是hql和缓层

感觉
1 那个schema应该是非transactional的设计。。。不是个好设计
2 对bean的作用域封装的不太清晰。比如你fill了一个东西以后在去fill，应该是update了。。。或者这个bean有争抢，delete以后再fill会发生一些很神奇的事情。。
3 没有把cache考虑进去。这个的确是很困难的。
4 transaction的封装不是OO的风格。。。insert或者是delete怎么能使transaction的责任呢。。。。明明是bean自己的事情。。。

反正。。。lz思考的还比较浅。。。不过我估计深入了，也就复杂了。。。SQL本身就是FP的东西，OO化不是很简单的。。。

POJO类，一个DAO类，一个*.hbm.xml映射文件 除了*.hbm.xml以外 另外2个跟hibernate无关
pojo 和dao是我们设计分层的时候加入的 所以说来hibernate跟你的orm比起来就多个*.hbm.xml
这个配置文件大家知道数据映射用的 LZ你的orm没有这个类似的文件 那你bean的字段名和数据库列名是根据自己定义的某种规范来起的吧 或者直接就是你例子里的 取一样的名字, 你能把数据库一个叫id的字段映射成bean中的name字段吗？

1、Schema是可以加入事务的，其实你说的第4点说明你已经看到了。
2、可能你没有太明白这个东西，fill()只是根据主键取数据，一个schema可以fill多次，每次都是取数据，比如说可以设置setID(1)后fill一次，然后取其他字段的值参加运算，再setID(2)后fill一次，取第二条记录的字段值参加运算。如果主键对应的记录不存在，fill会报异常。总之一切围绕主键。
3、有外挂式的Cache，能够与Memcache集成。我觉得一方面数据库本身已经有很好的缓存策略了，另一方面内存中数据的缓存有一个与ORM无关的实现可能会比较好。
4、我倒是不觉得有什么不OO的。在一个事务的一系列操作中，由事务负责哪个数据执行什么操作是很自然的事情。特别是这样子应该是代码行数最少的写事务的方式之一。OO不OO其实我并不那么关心，我只关心我要写几行代码。


其实就像上边回帖说的那样，这不是我的独创，思想本身来源于一个规模比较大的公司，国内有不少公司在用类似的方案。而且本身这个ORM框架已经经过了很多项目检验了的，效果是很好的。

希望楼主介绍一下如下两个问题:
1.关联的问题,一对多,多对多是怎么实现的,
2.还有对象/关系范式不匹配的问题是怎么解决
比如说两个表user,address对应一个User对象
user表
id  name addressid

address表
id  province country

User对象: id name address

这个倒不是问题，hibernate现在也支持注解配置，他写的这个东西实际上也可以引入注解解决你说的映射问题。

就LZ的话来说 如果他引入注解配置 那么就跟hibernate无异了

  缓存策略呢

楼主解决方案其实真的没有hibernate来的简单
用上hiberante注解配置
我也就只需要一个POJO，其他什么也不要。你这里唯一的好处是类对象可以有fill update delete的操作
你的实体类如何获得这种操作？？是因为它继承了schema！！！我需要的话也可以写一个针对hibernate的schema基类，获取sesseion实现你所谓的fill update delete操作。

你的QueryBuilder也就仅仅是一个弱化版的session，还没有session的可重复读,对象一致性范围等等的功能。说穿了你的QueryBuilder就是一个sql执行器。