21

场景

  • 您已经使用 EJB 版本 3 开发了一个 webapp。
  • 该系统由客户部署、交付和使用。

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

否：不要回答这个问题，而是回答这个问题。

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

让答案只包含一个问题。这将让其他读者投票选出 EJB 的最佳特性。

4

6 回答 6

5

我认为这取决于您正在谈论的 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，而且它还有一些更高级或企业级的可用功能。

于 2008-09-19T21:18:50.897 回答
2

嗯，这实际上取决于我们谈论的是哪些 EJB。我想说的是，即使是现在，MDB 仍然有用。对于实体 bean 和会话 bean，您肯定可以找到更好的方法。也许我仍然喜欢 EJB 的一个特性是可伸缩性。如果需要，您可以使用“远程”选项将 EJB 部署到不同的服务器。但是，我不认为这真的有必要，而且我只见过一个非常有用的大型项目。

于 2008-09-19T21:02:13.370 回答
1

过去使用 EJB 2.1 做了很多工作，很高兴将其抛在脑后。

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

诚然，我使用 Hibernate 和 Seam 来进一步构建 Java EE 的一些特性，所以说 EJB 3.0 本身就是圣地对我来说是不公平的。然而，我发现有太多的开发人员在完全放弃 Java 并转向像 Rails 这样更流行的东西时，就把众所周知的婴儿扔了出去。

Seam 提供了一个很好的胶合框架，它使程序员的工作量非常低。当 EJB 与 POJO 更有意义时，还可以让您逐个项目地决定，而不必改变您的编程风格。

于 2008-09-19T21:42:26.313 回答
1

使用 java ee 平台的主要原因是根据定义。您需要一个在经过全面审查、合规和兼容的平台中解决并发、可用性、事务管理、消息传递和管理问题的平台。是的，您可以通过将大量库粘合在一起并将其放在 tomcat 之上来自己完成这一切，但是当您可以写入执行标准、经过全面审查的平台时，为什么还要浪费所有时间审查和管理兼容性和功能集。任何 ee 容器都必须通过 tck，否则它不能携带 Java EE 名字对象。

各种人提出的关于ejb的“轻量级”，“类型”等的东西都是多余的。如果您不需要平台的功能集或保证所利用库的完全内部兼容性，那么 ejb（又名 java ee 平台）就过分了。但如果你真的要解决企业质量问题（见第一段），那么 ejb 和 java ee 平台将为你提供你所需要的。

于 2014-09-02T02:05:15.937 回答
0

在使用 EJB 或一般的 J2EE 时，让很多人感到困扰的一件事是对运行 EJB 的应用程序服务器的依赖性。应用服务器倾向于支持一组特定的操作系统版本和 JVM 版本。没有运行时环境的重要部分的源代码也可能会变成一个挑战。

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

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

于 2008-09-20T18:46:51.783 回答
0

约定优于配置。

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

于 2009-05-26T08:14:07.277 回答