java - EJB 和现代 Java 开发

Question

我是 Java EE 的新手，看到 EJB 在纯 Java/Oracle 社区中非常活跃。然而，工作中的每个人，每当有人说出“EJB”这个词时，他们的脸上都会露出厌恶的表情，这让我觉得他们要么正在灭绝，要么已经被具有其他中间件技术的现代开发团队所取代。

就像 JSP 已经让位于以 JSF 为中心的 View 技术一样，EJB 也是如此吗？无论哪种方式，EJB 的流行替代品有哪些？它们有何不同？与 EJB 相比，它们提供了哪些好处或特性？

Answer 1

您的同事可能只见过 EJB2 和更早版本，它们确实是很少有人喜欢使用的邪恶野兽。

在 EJB2 中，对于最简单的事情，必须实现非常侵入性的框架提供的接口(interface)，使用疯狂的生命周期方法，要求开发人员提供实现，但与开发人员的(业务)目标无关。必须提供一些这样的工件。

此外，每个 bean 都必须与非常冗长且难以阅读的部署描​​述符(一个 XML 文件)中的条目保持同步。好像这对开发人员的侮辱还不够，必须使用特殊工具来“增强”bean 并生成代理类、骨架和 stub 。不支持诸如继承之类的常见面向对象。有一种注入(inject)，但存在一种奇怪的注入(inject)，将事物放入一种与每个 bean 关联的映射(实际上是目录)中。

最初的 EJB 1 模型强制所有通信都是远程的，所有对象都是分布式的(EJB 最初只被视为一种远程技术)。因此，为了获得 EJB 的好处，您还被迫使您的体系结构分布式，即使这完全没有必要。

也许最大的侮辱是实体 Bean 的概念(不要与 JPA 实体混淆)。这种类型的 bean 的缺陷是如此之大，以至于即使是当时 EJB 的最大支持者也几乎无法向任何人推荐它。

那么作为一个非常实际的问题，EJB 实现之间的兼容性至少可以说不是很好。特别是实体 Bean 需要大量供应商特定的配置。

最重要的是，EJB 实现需要重量级(就安装大小和所需内存而言)应用程序服务器，这些服务器是封闭源代码且相当昂贵(因此阻止公司升级或切换，因为必须首先收回投资)。我不记得当时有多少人在博客上讨论这项技术，据我所知，这项技术主要是由销售团队向大公司的经理推销。

普通开发人员并不真正喜欢这项技术也就不足为奇了。

Sun 及时意识到该技术正朝着完全错误的方向发展，并进行了 180 度大转弯，并开始了大规模的重新设计工作。

因此，EJB 3 (2006) 是一种非常理智和轻量级的方法。不需要实现框架接口(interface)，不需要 XML，只需要编码一个 bean(只是简单的 POJO)，到处都有合理的默认值(约定优于配置)，不需要特殊工具(普通的 javac 将做)，而在本地使用简单的 bean 实际上是现在常见的情况。

Entity Beans 是如此有缺陷，以至于它们被完全丢弃，取而代之的是 TopLink 和 Hibernate 等倡导的更明智的方法。

将此与免费、轻量级和开源实现的广泛可用性相结合，再加上许多倡导该技术的知名博主(例如 Adam Bien、Rezha Rahman、Gavin King)，重新流行起来很容易解释。

最近发布了许多“Spring to Java EE”迁移指南，这些指南在各个新闻网站上获得了非常多的票数，许多人表示支持 EJB 现在是一项非常好的技术。这在五年前是不可想象的(当时 EJB 3 刚刚发布并且还不为人所知)。

EJB 最常见的替代品是 Spring Core(Spring Beans)。目前我认为 Spring 与 EJB 相比没有明显的大优势，反之亦然。这两种技术非常相似。 Spring 提供了一些更方便的实用程序，而 EJB 在概念上更轻量级(没有 XML)。这两个优点都有些主观。他们通常会受到彼此功能的启发，谁稍微领先通常取决于上次发布主要新版本的技术。