Bang大哥小弟想请教一下ORM框架

我个人意见是：ORM实际是Object --> Relation映射，关键是Object，首先自己要树立使用对象分析设计程序的习惯，对象在哪里生存？对象在计算机内存中生存，对象也可能变型睡在数据库中，当对象需要变形睡到数据库中时，就需要ORM框架这个魔法师来帮忙。

因为对象可以变形睡到数据库中，这样，虽然计算机系统关机了，但是对象就可以活得很长很长，下次计算机开机又可以活过来，这就叫持久活着（就是万岁，长生不老，除非磁盘坏了），ORM是解决对象如何持久的框架，或称持久化框架。

学习ORM框架等Hibernate前，我们可能学习过数据库，这时一定不能先在脑子有数据表结构，然后再想如何用Hibernate，这就倒过来用了，倒着用一个工具怎么可能用好呢？就象用剪刀，你握住的是不是把手，是刀口，能不伤害自己，能不感到痛苦吗？

所以，首先要有对象分析和设计（例如学习Evans DDD），再使用Hibernate解决对象长寿问题，使用ORM框架就是纯粹技术层面的细节活，就像建筑装潢，首先要有设计，然后才是使用什么工具和材料的事情。

Thanks!

学习Hibernate需要从对象开始入手，而不是数据表，忘记数据表细节。

相关帖子：

http://www.jdon.com/article/22244.html

如果已经先有数据表，再试图使用Hibernate来反推出对象，非常困难和麻烦，不推荐这种ORM使用方式:

http://www.jdon.com/jivejdon/thread/31803.html
[该贴被banq于2007年05月28日 12:22修改过]

当前Java软件开发中几种认识误区:
http://www.jdon.com/mda/nlayes.html

有人感觉使用Hibernate影响思路，这是因为数据库思维作怪，如果以为有了关系数据库知识，就能学好用好Hibernate，那就错误了，关系数据库是使用Hibernate最大的障碍。

http://www.jdon.com/jivejdon/thread/27886.html
[该贴被banq于2007年05月28日 12:35修改过]

顺便问一下：
不知banq大哥对ROR的ORM机制怎么看，能客观的评价一下吗？
现在小北弟正醉心于ROR，觉得它新特性的添加都似可以引起一些思想的变动，
不知您关注没有，比如REST,还有以前经常被质疑的“企业级”，RailsRonf 2007大会上好像交出了一些回应。

研究ROR，还不如看看Groovy On Grails，两个理由：
1、是java世界的。
2、不是日本的。

ROR的ORMapping机制不清楚，不过Groovy On Grails的机制还是Hibernate，同时也用了Spring的IOC反射模式。所以，有Java基础的朋友，还是GOG吧！
[该贴被wind13于2007年05月29日 11:02修改过]

>banq大哥对ROR的ORM机制怎么看
都差不多，因为都实现POEAA中的对持久层的要求，网上有这方面比较。
REST是表现层方面的，正在关注

关于ORM框架的学习和使用，有几种情况需要讨论，其实就是关系数据库和OO的配对关系，我列出下面三个常见的现象，如果关系数据库知识不好 OO也不好就不能做软件了，这不在讨论之列：
1. 关系数据库好 ；OO不好
2. 关系数据库一般 ；OO好
3. 关系数据库差 ；OO好
根据几年来J道提问题情况和我培训经验，前面第一种情况无法轻便使用ORM等Hibernate框架概率更大一些，会觉得Hibernate越用越复杂。

后面两种情况反而能用好Hibernate。

关系数据库中最重要一个环境是事务，MartinFowler最近一篇文章：Living Without Transactions

Martin Fowler (敏捷大师)发表了一篇blog,是关于放弃数据库事务管理,以依靠程序代码来管理事务的方法替代对数据事务管理的依赖.也许有时候这也是个正确的解决方案.
在 Transactionless 这篇blog中,Martin Fowler 对eBay的架构师DanPritchett最近的一次关于为什么eBay的架构师并不十分依赖数据库事务处理的演讲发表了评论. ebay的数据的完整性是由应用层代码完成的. Fowler 指出.

不用事务管理的根本原因是它在某种程度上损耗了eBay的处理效率. 这种影响因为eBay非常大量的将它们的数据分割在很多很多的物理数据库里的事实而变得更加恶化. 结果就是使用事务管理就意味着要使用分布式事务管理,这向来就是需要谨慎的事情.

这种大量的分割,以及在性能问题上,让数据库扮演主要角色的做法意味着eBay不能够使用许多的其他的数据库工具.相关的完整性和数据的排序全是用应用层代码完成的. 它们几乎不能用到trigger和存储过程.

Fowler不加思索的指出事务处理是一个非常有用的数据管理工具,而且指出:

没有人想要把事务处理从工具里排除掉. 我没有足够的关于eBay的详细信息让我来判断放弃事务的对于eBay来说是正确的做法. 但是eBay的例子让我们明白,没有事务管理的日子并不是像人们想象的那样不可能.

除了成为一个我们值得考虑的一种替换方案的事实外,它也是一个例子表明非事务处理的方式的使用要比人们平时所认为的更加常见. 业务需要分多步走,而且和多个资源相关,而且时长时间的分布事务,或是资源不支持事务,这样的事情是常见的.

根据Fowler's blog写的,在应用层里控制数据的完整性需要非常的小心,还需要许多额外的代码:

你需要加倍小心你提交的顺序,让最重要的放在最前面. 每一步提交你都要检查是否提交成功了,如果失败了如何处理.

当开发人员观察放大企业应用程序时,经常会发现数据层是最终的瓶颈. 目前好像是出现了两种途径去提高数据库层: In-memory, distributed caches,such as Tangosol's Coherence and JBoss Cache, 和把大数据库分割成许多小的数据库,在这些数据库中横向的反数据集群.

在第一种方法中,缓存成了应用程序的主要持久数据目标了. 许多的缓存解决方案提供了他们自己的API,通过这些API,他们绕过了传统的企业数据管理接口,例如JDBC和J2EE事务管理.

非集群的数据库,在另一方面,需要应用程序管理多个数据库连接,很可能要依赖分布式事务管理来确保这些跨越数据库的操作的成功.分布式事务处理--特别是分布式事务处理的协调者,就成了又一个瓶颈和失败点,而且可测量性也有限. 就像Fowler的文章指出的,分布式数据库中利用应用程序协调跨越数据库的工作可以增加可测量性.

在你的应用中,你是如何避免让数据库成为一个(single point of failure??)个别的失败和可测量到的瓶颈的? 对Fowler的博客里描述的非事务处理类型的应用的你是如何考虑的?

引用网址"翻译家"：
http://docman.cn/docs/?id=6
原英文网址:
Transactionless
http://martinfowler.com/bliki/Transactionless.html

說的就象跳大仙的一樣，orm還是不翻譯成sql，只不過用別人的框架進行了映射

>說的就象跳大仙的一樣，orm還是不翻譯成sql，
说的不错，但是ORM封装了SQL，程序员就可以完全面向OO对象了。

这样，我们软件只要开始从业务需求设计出模型对象就可以了，然后再借助ORM持久化。

模型对象设计方式：
http://www.jdon.com/jivejdon/thread/32474.html

可以说，现在80%的程序员都是被培养出面向数据库的分析设计思想，而不是OO思想，这是两种不同世界观的问题，所以，一个数据库世界的人才会对OO有跳大仙感觉。

ORM不是问题，它的出发点很好，将持久层模型化，但新的问题又来了；解耦了SQL的同时却加上了HQL的束缚，HQL不也是晦涩难懂吗？也许我们不需要了解底层的机制，能做好OO就行了。
[该贴被boby2046于2007年08月18日 17:59修改过]

Bang大哥,说实话,我现在对这种ORM也是一头雾水,感觉好像OO碰到关系数据库就感觉不三不四了!我想知道,按照OO的想法使用数据库有什么利弊,最好能不能举个例子比较容易理解!@,谢谢!

小弟大一的时候自学的JAVA,到学关系数据库是幸好得到了banq老师的指点。

现在倒并不觉得Hibernate难以使用,利用object mapping relation table

而不是relation table mapping object