新闻正文
都差不多，因为都实现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的博客里描述的非事务处理类型的应用的你是如何考虑的?对象在计算机内存中生存，对象也可能变型睡在数据库中，当对象需要变形睡到数据库中时，就需要ORM框架这个魔法师来帮忙。
因为对象可以变形睡到数据库中，这样，虽然计算机系统关机了，但是对象就可以活得很长很长，下次计算机开机又可以活过来，这就叫持久活着（就是万岁，长生不老，除非磁盘坏了），ORM是解决对象如何持久的框架，或称持久化框架。
学习ORM框架等Hibernate前，我们可能学习过数据库，这时一定不能先在脑子有数据表结构，然后再想如何用Hibernate，这就倒过来用了，倒着用一个工具怎么可能用好呢？就象用剪刀，你握住的是不是把手，是刀口，能不伤害自己，能不感到痛苦吗？
所以，首先要有对象分析和设计（例如学习Evans DDD），再使用Hibernate解决对象长寿问题，使用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的博客里描述的非事务处理类型的应用的你是如何考虑的?
收藏到ViVi 收藏此页到365Key
上一篇：
JDBC中的日期问题 下一篇：
JAVA的网络编程入门教程
