译文：我是EJB支持者，不只是Session Bea，还是实体Bean

本文翻译自 http://www.theserverside.com/news/thread.tss?thread_id=28608

　　我是一个EJB支持者，不只是session beans，而且是实体Bean，我站在你面前，用我的真实姓名，说：我喜欢用实体Bean。

　　当然，我也是对立方成员，我曾经用过Hibernate，也用过自己的放在这里放在那里的DAO框架，我当然不惧怕JDBC或XML，我也曾经研究过JDO。

　　我想，我如此积极提倡实体Bean是受到争议的，因为，很多人包括他们周围的“兄弟”都乐于公然地抱怨和埋怨痛苦的EJB是：“当然 session bean不错，特别是无状态session bean，但是实体Bean是糟糕的”。

　　我还是不同意. 我认为CMP beans只是中间产物(banq注：JDBC和O/R Mapping之间过渡产品). 如果你的数据足够粗粒度或者你有为数不多的实体数据，CMP是相当不错的，但是通常人们视实体Bean类似Hibernate中一个不起作用的持久类，其实，在另外一方面，他们是容器级别的抽象，不是一个Classloader之类如同Hibernate中的session的东西。无论你如何配置他们，你都可以得到相当好的弹性和适应性（banq注：这是我说的数据表级别重用）。

　　如果你问我BMP实体Bean情况，那么，我猜测，你肯定从EJB嵌入在服务器级别的缓存和分布式计算的classloader层尝到了甜头，Hibernate能给你这些东西，但是你需要投入足够的工作量才能获得，这些工作量如果使用EJB就本可以节省忽略，狂热的行为在你需要做更多工作情况下是害人的。

　　我认为最主要问题是，Java程序员没有脱离C语言的影响，在C中，如果你编译了，你就可以交付使用了；在Java中，编译然后创建一个Jar后，你才可以交付使用，好像Java程序员已经不同于C了，需要等待长长的琐碎的为企业应用而进行的有关可交付使用的各种配置过程。

　　这是一个错误，按照我的意见，J2EE标准一直强调：部署不同于编译，J2EE开发队伍中应该有很多部署员岗位，但是，一个程序员经常是自己程序的部署者，如果必要他也会测试（每个人都会测试，对吗？），这样就混乱了本来部署应该是独立的一个步骤。

　　这样，人们开始不满颠覆了，必须更换新的帽子，这么说，因为他们花费了大量时间和精力在原来的开发方式和所谓的编译时间上，其实，这应该是部署时间。

　　这是不行的，它意味着程序员的选择直接影响了企业系统。这种选择经常表现出来好像没有问题，但是， 人们很短视，我的数据表名在当地部署是正常的，但是在企业层面，也许不是那么一回事，如果我戴两个帽子，部署者可以在部署时配置数据表名称，而我在开发时使用我自己的数据表名称，这就不影响交付过程（意思：使用实体Bean，开发者可以设置自己的数据库表，当部署时，部署员更改一下数据库配置就可以切换到正式数据库，不必修改程序或重新编译了。）

　　我并不是说立即停止运行Hibernate（banq注：有些人还要将CMP实体Bean迁移到Hibernate，我认为是瞎折腾）.我自己现在还在使用它，但是我和它相处并不快乐, 这只是Hibernate强加给程序员的决定，我认为开发人员并没有水平能够做出所有可伸缩方面的决定。

posted Thursday, 9 September 2004

原文 http://epesh.blog-city.com/read/810641.htm

更多实体Bean专题

更多POJO专题

EJB

Hibernate教程