在过去 EJB 1.X 和 2.X 的时代，许多 Java 企业应用开发者有过一些使用 Enterprise JavaBean 的经历，但多数开发者仍继续选择他们所相信的更轻量级的技术，例如 Spring 框架，因为他们感觉手工构建解决方案，或者使用轻量级框架构建解决方案都比用 Enterprise JavaBean 更容易、更省时。
Jave EE 5.X 和 EJB 3.X 都在探索简单和更轻量级开发实践；POJO 解决方案更简单且有更易理解的代码，这种论调依然成立吗？Adam Bien 不这么认为：
实际上简化 EJB3.0 是困难的（真诚欢迎提出意见）。 有趣的是：没有 EJB 3 Session Bean 的 Java EE 5 Web 应用更复杂。
他用两小段代码做示范，一个用 EJB 3，另一个不用，结论是：
代码不但简单而且清晰。资源由容器来管理并注入。但是由于引入一个单一的 Session Bean，易管理性和监测性可以得到显著提高。使用象 Glassfish 这样的工具调用流程，你可以监测到整个调用栈的性能。最酷的是——XML 配置是可选的。在 EJB 3.1 中，甚至本地接口都是可选的。
Matt Corey 补充道:
一个有趣的话题是，在 EJB 3.1 里，将不再需要把你的 EJB 在 Web 应用之外单独打包……JSR 中描述：“在 servlet 容器中支持直接使用 EJB，包括被简化的打包选项”
Jason Carreira 提供了一些对比：
情况是，正如 EJB 3 比 EJB 2.1 好很多一样，Spring 比 EJB 3 好很多。比起 Spring 提供给你的将调用栈串接起来的强大功能，EJB3 依赖注入显得相当弱。 再加上，当我可以只需带上总是有一致实现的 Spring jar 文件时，为什么还要忍气吞声的去适应依赖于不同应用服务器实现的 EJB 规范？如果我决定坚持使用 Spring 的特定实现，我可以把那个实现带到任何应用服务器或 servlet 容器，而且，如果规格发生了变化，只要我不想，就不必升级或改变我的代码。你的最新版应用服务器会在 5 年内一直运行 EJB 3 吗？10 年呢？或许会，或许不会。
Spring 和 EJB3 之间的比较是非常普遍的；许多人由于Spring 遗忘了EJB 1.X 和 2.X 的复杂性，现在他们可能发觉自己会疑惑与EJB 3 相比会怎么样呢？或许大量的开发者转移到了Groovy 和Grails，或Ruby 和Rails。
有了EJB3 的Java 企业版比没有EJB3 的更简单吗？如果你已经使用了以前版本的Enterprise JavaBean，新的简化会帮你鼓起勇气去使用它们吗？
查看英文原文： Is Java EE 5 easier with EJB?
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论