J2EE without EJB

对于要求分布式事务的系统而言，EJB仍然是J2EE领域的一个较好的选择，Spring很好，但是它的定位是轻量级的，EJB是重量级的组件，在轻量级应用的领域来比较Spring和EJB并不合理，EJB肯定还会发展下去。

    就我个人的经验，EJB的技术门槛并没有那么高，实际一个有一定规模的项目开发过程中，如果有好的IDE的支持，仅仅就开发管理的效率而言，高于最传统的JDBC编程方式，EJB的开发调试工作并不是J2EE项目的开发瓶颈，其它的EJB本身的优势就不多说了。

    另一方面，就运行的性能来衡量，大数据量的操作当然不是Entity Bean擅长的领域，至于大负载下的性能，我想应该更多的是EJB设计模式、EJB的使用方式以及AppServer性能优化的问题，并不是EJB规范自身的问题，电信级的项目中成功使用EJB的项目并不少。

    个人觉得很多人对EJB的抵触很多是因为一种畏难的情绪，作为重量级的组件，EJB在J2EE领域仍然有巨大的价值，还会不断的发展和完善，这当中最要改进的就是其易用性的问题，但我不能因为一些缺点就否定EJB，Spring等轻量级框架并不能代替EJB。

    EJB仍然有很强的生命力，绝对没有式微一说。

我不大相信。就算是传统的JDBC，或者用iBatis做个简单封装，起码单元测试很方便。EJB最大的问题是单元测试太麻烦。我在P4 1.7G+1GRAM的机器上WebLogic部署一次需要两分钟，你说这叫我怎么做单元测试？好嘛，我写20行代码只要三分钟，然后就得花两分钟跑测试，还干不干活了？



轻量级框架的支持者们从来不会像某些EJB迷那样，认为有一种“one-fit-all”的solution——用dlee的翻译词汇来说，抓着把锤子就把啥都当钉子敲。lightweight solution的最大特点就是灵活的可接插性，你需要什么功能就插上什么功能，不需要的功能不必为它买单，但EJB就做不到。EJB只能笼统地说一句“这是个企业级应用”，然后一股脑地把所有东西都塞给你。

从某种意义上，我认为情况和你说的恰好相反：很多人对EJB的青睐、对lightweight solution的抵触才是出于畏难情绪。他们不愿意、甚至是没有能力分析清楚自己的application到底需要哪些infrastructures，所以他们也没办法选择自己到底需要哪些功能，所以他们才那么坚定地抱着all-in-one的EJB模型不放。因为不管他的application是不是需要distributed architecture，不管是不是需要declarative transaction，总之EJB什么都提供了，即便不是很好的方案至少也不会有大错。

另：有没有生命力，你说了不算，我说了也不算。明年夏天一过，EJB 2.x就被整体放弃，变成一种应用广泛的遗留技术。有没有生命力，一看便知。

我的前提是“有一定规模的项目”，若是一个简单的JDBC调用，开发效率当然远远超过编写一个Session Bean的方法，但是，如果项目有一定的规模，事务的操作比较复杂，若基于JDBC的最传统的开发方式，大量的sql语句，复杂的事务管理，手工开发、管理，效率、质量都难保证，这和EJB基于声明的、可配置的、容器管理的复杂事务模型来比较谁更有开发效率（我还有一个前提是良好的IDE支持），EJB给你提供的不仅仅是分布式的优点，当然更多的优点我一时也难罗列清楚。至于EJB测试的问题，我不清楚你部署一个EJB为什么需要两分钟，每一个EJB实现都是可以单独测试的，基于组件化的充分分工完全可以保证EJB测试的效率，至于你采用什么方式来测试，目前也有很多的选择：JBuilder自带的EJB测试、apache的Cactus、自定义Junit扩展，虽然本质上都是基于Junit，但你可以有多种选择，在我两年前的一个项目中，有这样的一个EJB模块：business facade层一个Session Bean，大概二十多个业务方法（我没有再使用业务代理分层，业务方法比较多），Entity Bean为5个local Entity Bean，每个Entity Bean的“字段”数平均大概30个左右，最多的一个有60个左右，应该算一个比较典型的基于J2EE facade模式的一个EJB模块，开发环境为JBuilder7+Weblogic7+Oracle8，每次部署的时间绝对不超过20秒，当然你要是每次重部署时都去使用EJBC编译一次，时间肯定会变得很长，我当时的机器内存还没有你多，我不知道你的两分钟从何而来？测试是用JBuilder的Junit实现，整个开发流程中绝对没有影响项目的进展，反倒是Web的开发成为了瓶颈。



首先申明一下，我绝对不是什么EJB迷，更不赞成什么all-in-one的想法，我恰恰十分喜欢Hibernate、iBatis，也打算研究Spring，但是我不认同“EJB会逐渐式微”的说法，重量级的组件应该用在重量级的应用中，轻量级的组件框架当然应用在轻量级的应用中，只要企业级的应用中需要重量级的组件，需要分布式事务，需要高度的可扩展性，EJB就仍然有生命力，至于EJB3.0，虽然借鉴了Hibernate、Spring的优点，但它仍然是EJB，它仍然是分布式的重量级组件，EJB3.0规范的草案并没有禁止EJB2.X，就像EJB2.X没有禁止EJB1.0一样，兼容问题更多是AppServer实现者的问题，EJB作为一个重量级的组件并没有消亡，仍然在不断的进步。至于“可接插性”的问题，EJB规范本身就是一个基于动态对象模型的接口标准，而且是一个业界的标准，怎么会不能灵活的实现“接插”？你不需要remote EJB，完全可以定义本地EJB；你担心Entity Bean的性能，完全可以仅仅使用Session Bean + Dao；你讨厌XML声明式的事务，你完全可以在Session Bean方法中自己操作事务；你不喜欢PC机调试的缓慢，完全可以在远程小型机上部署+本地测试，我还是那个观点，对EJB的抵触有时是一种畏难情绪，EJB实践中出现的问题更多的是EJB设计模式、EJB的使用方式以及AppServer性能优化的问题，绝大部分是最佳实践的问题，不是EJB规范的问题。

EJB仍然有生命力，没有式微一说。

有什么大事发生？是指EJB3.0发布吗？

问题在于，我们并非只有（a）EJB（b）“基于JDBC的最传统的开发方式”这两种选择，所以你这些论述其实没多大意思，仅仅证明EJB或许不是最差的solution而已。就拿declarative transaction来说吧，究竟是EJB的比较容易用还是Spring的比较容易用，我相信自有公论。

这个，就是我所说的“architect的畏难情绪”。这些话，如果是marketing的同事拿去跟客户讲，没问题，我绝对支持。但既然我们都是做技术的，既然我们都是architect，恐怕不能拿“重量级的组件应该用在重量级的应用中”这种话来敷衍。我要问了，什么叫“重量级的应用”？一个网站每天有100万PV，2000人同时在线，够重量级了吗？但EJB帮不了忙，因为它需要的是web server clustering。同样的，我还要问，什么叫“高度的可扩展性”？我希望随时可以给business object加上各种拦截，今天加个logging的拦截器，明天加个exception handling的拦截器，后天加个remoting的拦截器，这是高度的可扩展性了吧？可这恰恰是lightweight solution所擅长的、EJB所不擅长的。

所以你不能这样笼统地说“重量级应用”怎么怎么样、“企业级应用”怎么怎么样，那行不通，那是marketing拿去哄客户的话。企业级应用就一定要企业级JavaBean，重量级应用就一定要重量级solution，这种道理在JavaEye这里是不会太有说服力的。

http://blog.iteye.com/index.php?op=ViewArticle&articleId=349&blogId=1

连人家IBM的客户都旗帜鲜明的拒绝EJB了，你还在唱颂歌？咱们不谈技术上好坏，单单说说市场上面的接受程度，也已经彻底完蛋了。

“architect的畏难情绪”！第一次听说，新鲜。

关于什么叫重量级，什么叫轻量级，什么叫企业级应用，什么叫可扩展性，我不想多争论，只有一个业界的俗称，不是什么市场人员和技术人员的不同用词，没人会给你什么权威的定义，仁者见仁，智者见智。

作为一个轻量级框架最大的优点当然是灵活性，这没什么奇怪的，反之，你让一个轻量级框架实现一个分布式事务系统，实现是一个基于集群的负载均衡试试？一个基于Spring框架的系统如果不能满足实际的性能要求，你来告诉我如何扩展？换更高档的机器？还是你自己基于Spring去实现集群？再有复杂的分布式事务，你用Hibernate试试？真能做到这些，那你可以自己去设计个轻量级分布式J2EE框架了。

千万不要说集群和EJB本身没有关系，正是因为EJB的设计要求之一就是要满足分布式，集群扩展的要求，AppServer才能实现基于集群的扩展性。

打个比方：Spring之于EJB，就如巴雷拉对泰森，谁赢？

不同的组件规范和框架都有各自的优缺点，也有各自不同的擅长领域，不能因为喜欢一个就去全盘否定另一个，非黑即白的思路要不得。

至于robbin说IBM的客户拒绝EJB，这有什么奇怪的，我在一个帖子里还看到有客户一定要求用Struts，个案而已，IBM自己并没有拒绝EJB。

另：我可不是为EJB唱喜歌啊，只是不认同什么“EJB式微”的说法。

你看看，我说什么来着？architect的畏难情绪马上就体现出来了。分布式事务可以用JOTM实现，如果你不想自己看文档可以请本论坛的Quake Wang给你做培训。基于集群的负载均衡不是任何一个组件模型的任务，既不是Spring的，也不是EJB的，那是application server的任务，Resin和Weblogic都可以实现，到servlet container这一层就已经完全不知道前面有没有负载均衡了。



我完全赞同，一直以来我都完全赞同。但是不行，你不能只说一句“非黑即白的思路要不得”就把我打发了。这在你的老板、你的客户那里或许行得通，在我这里行不通。你得告诉我，究竟什么情景适合用EJB。你已经举了两个例子，很遗憾的，你的两个例子都被我证伪了。看起来，如果你要让我相信EJB是好的，还得再费点脑筋找个好例子。