|
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-06-06
已经有很多种实现了。 grails 中的 gorm 就是这种 形式的， 虽然 它在底层是借助的 hibernate， 但是在 api 的形式上 都是直接的 domain.get(id) domain.find(expression) domain.findAll(expression) 等。
不过它 的 实现不是用的继承， 而是用动态修改 class ，为 domain 添加 动态行为实现的。 此外还可以用 findByNameAddress("abc","中国") 的形式。 连拼SQL都省了，可以直接拿 字段名做查询方法。 |
| 返回顶楼 | |
|
发表时间：2009-06-06
Schema中的代码没贴出来？到底是怎么样跟数据库表产生orm关系的呢
|
| 返回顶楼 | |
|
发表时间：2009-06-06
最后修改：2009-06-06
楼主描述的这个框架的行为确实可以用Hibernate完美模拟 因为全部是Hibernate的子集而已
说Hibernate复杂 不过是Hibernate帮你考虑了更多的事情 但是通常情况下你更本不用关心 因为Hibernate是透明地帮你做了这些事情 比如 底层数据库的任意替换 数据库自动建表 缓存(Hibernate也是用的第三方缓存工具, 而且是完全可替换的) 复杂关系映射关联 面向对象的查询语言HQL 编程化的查询QBC 按照例子查询QBE EJB3,JPA支持.. 太多太多 Hibernate的完善程度恐怕已经没有框架(TopLink也许和它接近 毕竟Hibernate从他身上学了很多 但是早就青出于蓝了)能和它相比了 所以gorm并没有自己搞一套 而是直接在Hibernate之上 让Hibernate更方便使用 phoenix.clt 写道 已经有很多种实现了。 grails 中的 gorm 就是这种 形式的， 虽然 它在底层是借助的 hibernate， 但是在 api 的形式上 都是直接的 domain.get(id) domain.find(expression) domain.findAll(expression) 等。
不过它 的 实现不是用的继承， 而是用动态修改 class ，为 domain 添加 动态行为实现的。 此外还可以用 findByNameAddress("abc","中国") 的形式。 连拼SQL都省了，可以直接拿 字段名做查询方法。 最近正在关注 Groovy, Grails。 对Java程序员来说他们确实是很有意思的东西 |
| 返回顶楼 | |
|
发表时间：2009-06-06
即然挑战hibernate 那就作为一个开源项目发布一下，拼拼，看谁到底更厉害，不过我觉得渺茫，hibernate 已经参加ejb3的团队了，最好弄个完整的东东，然后相对于hibernate的相同的操作，来个测试对比什么的！！
|
| 返回顶楼 | |
|
发表时间：2009-06-06
liujunsong 写道 学那个Hibernate就快把人搞死了,
现在用这个又要学新东西. 现在的技术啊,老是与时惧进,东西越来越多. 用这个东西也许能提高些效率,可是以后维护怎么办? 来的人还得从头开始学习,理解,消化... 不看好. 把目的搞清楚，学了是为了用，用是为了提高效率。 如果‘学那个Hibernate就快把人搞死了’的话，何必去学它？ |
| 返回顶楼 | |
|
发表时间：2009-06-06
但反观Hibernate呢？我们需要一个与StudentSchema类似的POJO类，一个DAO类，一个*.hbm.xml映射文件，才能达到类似的效果，机制繁琐，性能消耗明显要高。
------------------------------ POJO类是肯定需要的，楼主的也一样需要，是否需要DAO类完全是自定义的，如果你喜欢1个POJO对应1个DAO(甚至再加上1个DAO的接口)，都可以。如果你喜欢只用1个DAOHelper类也可以，只需要对hibernate做很简单的封装就可以了。hbm.xml也可以不用，使用JPA注解就OK。 其实怎么使用都看个人喜欢和水平。 |
| 返回顶楼 | |
|
发表时间：2009-06-06
用Hibernate很久了，觉得需要改进。
强烈关注你的作品。 |
| 返回顶楼 | |
|
发表时间：2009-06-06
hibernate最伟大之处 不是技术;
是-------推广成功,是统一; 技术的本质是什么? 看看李小龙电视吧! webwork 好还是 struts好 我04年用webwork后来跳槽一些面试者说你不熟悉struts什么的,就无语了 struts1+filter+interface+thking====??? 呵呵 技术不是唯一; |
| 返回顶楼 | |
|
发表时间：2009-06-06
wyuch 写道 1、Schema是可以加入事务的，其实你说的第4点说明你已经看到了。 2、可能你没有太明白这个东西，fill()只是根据主键取数据，一个schema可以fill多次，每次都是取数据，比如说可以设置setID(1)后fill一次，然后取其他字段的值参加运算，再setID(2)后fill一次，取第二条记录的字段值参加运算。如果主键对应的记录不存在，fill会报异常。总之一切围绕主键。 3、有外挂式的Cache，能够与Memcache集成。我觉得一方面数据库本身已经有很好的缓存策略了，另一方面内存中数据的缓存有一个与ORM无关的实现可能会比较好。 4、我倒是不觉得有什么不OO的。在一个事务的一系列操作中，由事务负责哪个数据执行什么操作是很自然的事情。特别是这样子应该是代码行数最少的写事务的方式之一。OO不OO其实我并不那么关心，我只关心我要写几行代码。 其实就像上边回帖说的那样，这不是我的独创，思想本身来源于一个规模比较大的公司，国内有不少公司在用类似的方案。而且本身这个ORM框架已经经过了很多项目检验了的，效果是很好的。 1 提供事物支持和transactional不可同日而语 2 哦，那我就是还看不懂你那个fill是什么意思 3 是说orm自己的cache。。。这个cache和memcache不是一个层次的。。。当然，你也可以选择，没有cache。。。就我个人而言，我的确觉得orm里面的cache把问题弄的过于复杂了。 4 哦，那我倒是觉得干脆jdbc代码最少了。。。 |
| 返回顶楼 | |
|
发表时间：2009-06-06
标题是"反思Hibernate"
这个标题的意思应该是,已经对Hibernate非常熟悉,有多年的应用经验,然后回过头来说说Hibernate的不足之处. 但是显然,LZ对Hibernate几乎不懂. Hibernate之所以复杂,是因为有了强大的关系支持,1对1,乃至多对多,都有了最合理的支持,而且为了保证效率,引入了一系列的辅助措施,Lazy,Cache等等. 所以配置选项非常多,感觉上要做一件简单的事情,也要配置一下. 但这个不是缺陷,这个是能力,是能够对应复杂情况的能力,就象用Java写一个HelloWorld,也要写一个class,还要有main,最终还要编译... 我完全相信可以开发一种语言,专为输出HelloWorld,只需写一个字就可以执行... 你能说比java更好吗? LZ的方案,简单讲,只是省略了一些sql.用了自动化的代码生成工具,可以省去重复的代码编写. 这个思路,从OO诞生之日起,就已经在很多公司运用了. 当然,这是一个简洁有效的方案. 只不过如果要去和Hibernate比高低,那是自不量力了... 跟LZ的框架类似的,我见过的做的最好的,是.net平台下的SPL,国人的产品.只不过三年前就不更新了. 如果有兴趣,可以去参考一下. |
| 返回顶楼 | |
