评论

#非典型秃子 发表于2006-01-10 15:41:00  IP: 61.152.132.*

C++,也需要ORM啊！这确实是个讨厌的问题！

#风沙 发表于2006-01-10 22:09:00  IP: 61.171.211.*

业余跟专业的区别就在这
http://www.odmg.org/

#TN 发表于2006-01-10 19:42:00  IP: 202.77.139.*

dotNet下的ＯＲＭ类库很不错，试试ECO与ＸＰＯ，效果很不错，可是不像hibernate 哪样是免费的．也可以试试ＭＳ的LINQ技术，非常好用．

#charles 发表于2006-01-10 23:33:00  IP: 222.35.23.*

>问题是，上述的定义都在hbm文件，每种对象的载入策略只
>能定义一次。而不能像jdbc那样，根据不同的情况select不
>同的结果列。

你只是懂hibernate而已。JDO/TOPLink都可以提供灵活的加载方式(Fetch plan)，对多一个POJO的加载方式可以根据页面显示的需要进行定义。EJB3 SQL中的 fetch join 也可以让用户根据需要去加载需要的关联表。

#白衣 发表于2006-01-12 10:11:00  IP: 219.136.159.*

@charles
JDO/TOPLink的fetch plan我先去学习一下.EJB SQL的fecth不算啊,又走回sql手工定义选择列而已.

不过为什么fetch plan 进不了EJB3呢?还是进了我不知道?

#肥豆 发表于2006-01-11 10:42:00  IP: 210.22.89.*

现在所有的ORM,其实都是试图从O一方来解决问题，所以搞的很累，为什么不试图从M一方来解决了，如果数据库能直接提供对象，那不就不用这么穷折腾了吗！ :)

#肥豆 发表于2006-01-11 11:28:00  IP: 222.66.56.*

Cache数据库就是能在后台写对象，并支持现在几乎所有的主流前台编程语言，而且全面兼容Sql92标准！ 是个好东西

#charles 发表于2006-01-16 14:34:00  IP: 222.35.23.*

>EJB SQL的fecth不算啊,又走回sql手工定义选择列而已.
因为ejb3专家组的某专家认为用sql + fetch join就足够好了。

#k.o. 发表于2006-01-30 10:24:00  IP: 202.232.65.*

也许我已经太落后于时代了，我总觉得用什么ORM的工具都不如直接用SQL文来的方便。最多，也就是把ResultSet->Object这一块做成共通的。
原因是：
1.我们（指我和周围的一些人）考虑实现逻辑的时候，直接的想法就是根据什么条件取得什么数据，表和表怎么关联，表和表之间的关系是1:1还是1:n,要不要外关联等等。
本来就是R的东西，怎么转换成O来思考，请指教。
2.如果1是被认可的方式，那么这种思维的转换会增加复杂度；并且，写出来的东西不像SQL文那样可以直接在可执行SQL的Tool里面验证是否正确。至于Hibernate的Cache什么的，比如需要考虑防止多人同时更新的问题，很是让人头疼。
3.从群众基础的方面来考虑。很多ORM工具的宣传上说，可以让程序员摆脱DB操作，把精力放到业务逻辑上来。在我看来，不管是目前的工具还不尽如人意也好，还是数据库操作本来就是业务逻辑的一部分也好，这个目的都远远没有实现。我看到的大部分程序员，都谈不上是技术的狂热爱好者，也不是什么接受能力很强的牛人，让他们从头来学习一门几乎全新的技术，时间和经济成本都很大。这样的话，本来用ORM是想省事的，结果往往省不了事。现在版本更新这么快，Hibernate2学到的东西，居然出了Hibernate3还要再学习一遍:(相对来说，SQL是稳定的。从PM的角度来说，谁愿意冒这个风险，为了将来可能的生产力提高？
总结以上的，我不是说ORM不好，只是现实中往往有很多其他的东西需要一起考虑。
扯点题外话，我们费了老大的力气，搞定了Hibernate，最终客户却什么感觉也没有（也许bug率还会上升），是不是有点孤芳自赏的感觉？
所以，如果可以选择的话，我更愿意把精力投到ajax这样的，客户可以直接体会到差别的技术上来。
大家说呢？

#J++ 发表于2006-02-10 08:57:00  IP: 222.90.70.*

文章写的毫无意义
因为你只是固执的站在SQL人员的角度看待问题本身，而这些持久层的目的不是如此，况且持久层的选择与你是否继续使用SQL毫无关系，关键在于你的项目本身的类别，对于OLAP的类别根本不适合Hibernate这样的持久层框架的，况且Hibernate本身支持NATIVE SQL的形式！
所以，不要动不动就否定某个事物，而是要看到出现这个事物的目的是什么？！

#JAVA++ 发表于2006-02-12 22:40:00  IP: 219.134.244.*

ORM确实有我问题，是数据库外部Ｏ到数据库内部的Ｒ有问题，要是做到数据库外部的Ｏ和数据库内部的Ｏ直接对话就可以，只要有面向对象的数据库+面向对象的ＳＱＬ问题就都解决了，不用这么麻烦，还要做ＰＯ层，ＶＯ层转换来转换去的，人民内部问题，为什么要分开解决中间搭桥梁．

#肥豆 发表于2006-02-16 11:12:00  IP: 210.22.89.*

赞同JAVA++ 的说法！ 之所以会出现所谓的O/R Mapping的问题，就在于面向对象的编程语言和面向关系的数据库的之间的这个现实的矛盾，国内言数据库就是sql,oracle,sybase,db2 仿佛除了这些其他的都不是数据库一样，思想太局限了，死死的盯在关系型的数据库上面，还津津乐道。国外的对象数据库都弄的很不错了，都有段发展历史了，很多项目中oracle,db2都不是的可选的产品，因为无法满足系统的需求和要求！ 这也就是差距的所在啊。

#肥豆 发表于2006-02-16 11:17:00  IP: 222.66.56.*

数据库里能直接提供对象，那ORM还有存在的理由吗？ :).当然Sql语言还是有存在的必要的，至少在新的数据查询语言出来之前，它还是有存在的价值的，在数据查询和挖掘方面(OLAP)它还是有用处的。但在业务处理方面(OLTP)的作用会被更好的对象方式替代掉了。