场景

• 我们已经使用EJB版本3开发了一个webapp。
• 该系统已部署，交付并由客户使用。

如果必须从头开始重写系统，是否会再次使用EJB？

否：请勿回答此问题，请回答此问题。

是：根据个人经验，提供EJB解决的一个重要而实际的问题。

让答案只包含一个问题。这将使其他读者投票赞成EJB的最佳功能。

解决方案

好吧，这实际上取决于我们在谈论哪个EJB。我要说的是，即使现在，MDB仍然有用。对于实体bean和会话bean，我们肯定可以找到更好的方法。
也许我仍然喜欢EJB中的一项功能是可伸缩性。使用"远程"选项，可以在必要时将EJB部署到不同的服务器。但是，我认为这并不是真正必要的，而且我只看到了一个真正有用的大型项目。

我认为这取决于我们所讨论的EJB版本。让我们讨论仅有的两个相关(IMO)版本。

遗留系统中的某些人仍可能使用EJB 2.1. 实际上，它们最常用作RPC抽象。他们还提供了基本的ORM(对象关系映射)系统。正如我们提到的，提供了交易支持。因此，如果我们要构建一个系统来与远程系统进行通信，传输面向对象的数据并以事务方式进行处理，则可能会发现EJB是值得的。否则，我会说别走。

但是，EJB 3.0有了很大的改进。它具有先前版本的所有功能，但是以更直接的方式实现。它还提供了一个与Spring不同的相当简单的Inversion-Of-Control框架，以及一个JPA(Java持久性API)形式的相当不错的ORM。我曾经使用过EJB 3.0，并且很喜欢它。我们可能会像使用Spring一样主张使用EJB 3.0，此外它还提供了一些更高级的或者企业级的功能。

过去使用EJB 2.1做过很多工作，很高兴将它抛在后面。

EJB的价值主张对于3.0仍然适用，并带有一个不错的轻量级编程模型。事务管理，并发，数据版本控制，状态管理，这些都是正确解决的非平凡问题，并且Java EE框架继续做得很好。

诚然，我使用Hibernate和Seam进一步构建了Java EE的某些功能，所以说EJB 3.0本身就是麦加并不严格。但是，我发现太多的开发人员在完全放弃Java并转而使用诸如Rails之类的更时尚的产品时，就把这名婴儿扔掉了。

Seam提供了一个很好的粘合框架，使程序员的工作量保持在较低水平。还可以让我们根据项目决定何时使用EJB和POJO，而不必更改编程风格。

在使用EJB或者通常使用J2EE时，造成很多困扰的一件事是对运行EJB的应用服务器的依赖。对于特定的一组操作系统版本和JVM版本，倾向于支持appserver。在运行时环境的重要部分中缺少源代码也可能会带来挑战。

虽然原则上可以从一个供应商迁移到另一个供应商，但我们需要非常注意它们在实现规范方面的细微差异，并远离供应商特定的扩展。

话虽如此，我接触过的应用服务器可以处理其中运行的代码带来的大量滥用，并且性能非常好。

约定优于配置。

EJB 3的默认行为通常是所需的行为。我认为EJB 2.1的主要问题是冗长的配置文件的必要性，新的基于注释的配置解决了大部分问题。