场景
如果您必须从头开始重写系统，您会再次使用 EJB 吗？
否：不要回答这个问题，而是回答this one。
是：根据您的个人经验，提供 EJB 解决的一个重要的实际问题。
让答案只包含一个问题。这将让其他读者投票选出 EJB 的最佳特性。
【问题讨论】：
标签： java jakarta-ee ejb-3.0
嗯，这实际上取决于我们所讨论的 EJB。我想说的是，即使是现在，MDB 仍然有用。对于实体 bean 和会话 bean，您肯定可以找到更好的方法。 也许我仍然喜欢 EJB 的一个特性是可伸缩性。如果需要，您可以使用“远程”选项将 EJB 部署到不同的服务器。但是，我认为这并不是真的必要，而且我只见过一个真正有用的大型项目。
【讨论】：
我认为这取决于您所谈论的 EJB 版本。让我们讨论仅有的两个相关 (IMO) 版本。
EJB 2.1 可能仍被遗留系统中的某些人使用。它们确实最常用作 RPC 抽象。他们还提供了一个基本的 ORM（对象关系映射）系统。正如您所提到的，提供了事务支持。因此，如果您正在构建一个希望与远程系统通信、传输面向对象数据并以事务方式进行的系统，您可能会发现 EJB 值得付出努力。否则，我会说远离。
然而，EJB 3.0 已经有了很大的改进。它具有以前版本的所有功能，但以更直接的方式实现。它还提供了一个与 Spring 不同的相当简单的 Inversion-Of-Control 框架，以及一个相当不错的 JPA（Java Persistence 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 版本。没有运行时环境的重要部分的源代码也可能成为挑战。
虽然原则上可以从一个供应商迁移到另一个供应商，但您需要非常了解它们在实施规范方面的细微差别，并远离供应商特定的扩展。
话虽如此，我接触过的应用服务器可以处理其中运行的代码的大量滥用，并且性能非常好。
【讨论】：
约定优于配置。
EJB 3 的默认行为通常是所需的行为。我认为 EJB 2.1 的主要问题是冗长的配置文件的必要性，新的基于注释的配置解决了大部分问题。
【讨论】：
使用 java ee 平台的主要原因是根据定义。您需要一个在经过全面审查、合规和兼容的平台中解决并发、可用性、事务管理、消息传递和管理问题的平台。是的，您可以通过将大量库粘合在一起并将其放在 tomcat 之上来自己完成这一切，但是当您可以写入执行标准、经过全面审查的平台时，为什么还要浪费所有时间审查和管理兼容性和功能集。任何 ee 容器都必须通过 tck，否则它不能携带 Java EE 名字对象。
各种人提出的关于“轻量级”、“类型”ejb 等的东西都是多余的。如果您不需要平台的功能集或保证所利用库的完全内部兼容性，那么 ejb（又名 java ee 平台）就过分了。但如果你真的要解决企业质量问题（见第一段），那么 ejb 和 java ee 平台就会给你你所需要的。
【讨论】：