J2EE探险者: 持久数据管理，第1部分 - 编程入门网
| 是事务性组件，这些组件具有可配置的事务语义；而会话 bean 没有。将事务语义直接编码到应用程序代码中时，开发人员必须处处小心以确保每个功能的业务规则、流控制和事务完整性都得以保护并且可以容错。在实体 bean 开发中，这些细节都由容器处理。
持久性不是自动的或者得不到保证。在实体 bean 操作中，容器处理 bean 状态的持久性，并确保这种数据得到保护，供以后使用。对于会话 bean，将数据保持在安全、长期的数据存储中是开发人员的责任。 总之，与 JDBC 结合的会话 bean 遭受三个关键问题：bean 的实现常常是复杂的；会话 bean 没有固有的事务性；持久性机制不是自动的或者得不到保证。 J2EE探险者: 持久数据管理，第1部分(4)时间:2011-01-31 IBM Kyle Gabhart进行调用 尽管还有不足，J2EE 架构设计师已开始宣布带有原始 JDBC 调用的纯无状态会话 bean 是最安全和最受推崇的数据持久性机制。这并非主要因为该组合是优于实体 bean 的解决方案（两者各有所长），实际是因为它有推动力。在实体 bean 很快脱颖而出又很快失宠的时候，对会话 bean 和 JDBC 的接受程度却随着时间的推移缓慢而稳定地积累起来。 不管当前趋势是什么，仔细地权衡实体 bean 和会话 bean 与 JDBC 组合的优点总是值得的。下面的列表标识了比较这两个数据持久性解决方案的四个关键方面： 读／写需要。需要经常读取且从不更改或偶尔更改的数据最好由会话 bean 与 JDBC 组合来处理。开发工作会简单直接，并产生极好的响应时间。 如果数据需要频繁更新并支持许多并发请求（因此有许多并发更改），那么实体 bean 是当然的选项。在面对数据的并发请求时，为确保数据完整性、同步和频繁的持久性而构建一种机制所涉及的复杂性简直太难克服了，而且不值得花时间和精力来创建它。 事务支持。CMP 实体 bean 使开发人员不必关心事务环境。所有事务细节都在 bean 的部署描述符中声明。如果可以接受这一级别的控制，那么 CMP 实体 bean 无疑提供了最容易的解决方案。如果需要更多的控制，那么 BMP bean 允许开发人员定义应该采取的操作，而不必为应该何时触发这类操作来编写业务规则。对于最大级别的控制，应该使用会话 bean。会话 bean 会管理涉及 CMP 和 BMP 实体 bean 的复杂事务，以及少数直接访问数据库的 JDBC 调用。 上市时间。CMP 实体 bean 显然是所有 J2EE 持久性机制中唯一一个上市时间最快的。声明数据类型和名称，定义部署设置，然后由应用程序服务器和供应商工具负责其余部分。很难讲 BMP 实体 bean 和会话 bean 与 JDBC 组合哪个能排上第二快的解决方案。一方面，BMP 会更快，因为容器正代表 bean 提供如此多的生命周期服务。而另一方面，会话 bean 会领先，因为它们没有 BMP 那么复杂，所以构建／测试／部署周期更短。最后，在这三种解决方案针对您的特定项目时给它们排序只是整个比较过程的一部分。还必须针对下一个类别（资源使用情况）来权衡这个评级。 资源使用情况。实体 bean 因消耗大量的资源（尤其对特别大的实体进行并发请求时）而声名狼籍。与之相比，会话 bean 和 JDBC 数据源连接是非常轻量级的，只需要少量的服务器资源。有关这一点的更多信息，请阅读本系列的第一篇文章“J2EE technologies for the stateless network”（请参阅 参考资料中的 J2EE Pathfinder系列文章）中概述的无状态会话 EJB 实例-合用模型描述。 结束语 在 J2EE 探险者系列的第三部分中，我们针对数据持久性将实体 bean 与会话 bean 和 JDBC 组合作了比较和对照。这里讨论的方案并未涵盖所有情形，但是它们代表了实体 EJB 组件和会话 EJB 组件的一些最常见用法。 下个月，我们将通过比较实体 bean 和 Java 数据对象（Java Data Obje |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
