J2EE探险者－分析/对比J2EE技术的文章

http://www-900.ibm.com/developerWorks/cn/java/j-pathcol/

 

笔记：

实体bean VS sessionBean＋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 实例-合用模型描述。

• EJB－QL的教程：http://www-900.ibm.com/developerWorks/cn/cnonlinetutorial.nsf/gethtml?OpenAgent&url=/developerWorks/cn/education/webservices/ws-wscomp3/tutorial/ws-wscomp3-3-3.html