ORM框架学习

　　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的文章指出的,分布式数据库中利用应用程序协调跨越数据库的工作可以增加可测量性.